Robust, Reliable, Operation
Traditional solutions for achieving high availability 'on-demand' were achieved by regular maintenance. Even for mechanical systems this can bring modes of failure due to maintenance, rather than operation, but can be a costly and personnel intensive exercise. Electronic systems have very poor indicators of imminent failure that can be used for prognostics. Whilst some passive electronic devices may be able to be diagnosed, digital systems tend to be more recalcitrant.
Software systems are expected to be able to identify and isolate failures of system components (usually to a least replacable unit) in both themselves and their connected electromechanical sensors and actuation systems. In fact the majority of most software solutions, controlling major functional subsystems, design, development and physical size are generated in support of this, rather than the functional operation of the system.
If you add to these systems a need for redundancy required in mitigation to localised damage, or for continued operation in the advent of single failures, then significant system complexity ensues in managing the isolation of faulty (but not necessarily inoperative) equipments and is a significant attribute in defence applications.
Through-Life Functional upgrades.
Because of the long service life of most defence components, there is an inherent expectation that functionality will be enhanced through a vehicle's, or equipment's, lifetime. This may be in response to an improved offensive or defensive capability, or in pursuit of operational efficiency, safety, economy or changing theatre of operations.
Design tensions exist between ultimate flexibility, through use of largely uncommitted, although bounded, capability of modular electronics and the goals for optimisation (e.g. power consumption, volume, mass, thermal management).
Our ability to predict these, world politics driven, changes is poor, so the mitigation techniques we employ need to be well undersood by both designers and customers.
The fore-front of modern electronic equipment technology is no longer driven by the military. Electronic component suppliers work on tiny margins and profitability is driven by volume at very high yields. Selecting 'exceptional' parts (those whose tolerance stack-up gives them better than average performance) for extreme environments is no longer economic for those small markets. The availability and duration of components is driven by volume consumer markets and the cost economic of moving to newer, higher yield, fabrication technologies. These new technologies, materials and fabrication techniques are in tension with the needs for military use.
Although we can design for the expected life of miltary equipment, including strategies of total equipment refresh, these may involve costs that are akin to new development, have a long cut-over plan, and still be at risk of component availability.The service lives of defence equipments often extend beyond their original design parameters.
Portability a Key attribute
Software Systems are naturally linked to the electronic platform, both in terms of processing core choice, but also in terms of interfacing, being bound to certain types of inputs, outputs, communications busses, performance, timing and hardware pre-processing support.
In defence applications, like those in fast-paced markets, portability of the software, its partitioning and architecture, the binding of physical properties, the layering of services, the attributes of performance, the interface standards employed, all help mitigate the propagation of change and ultimately the cost of introduction of change.
The concept of flexible systems that can be configured to achieve many different roles, capabilities or goals is not new.
In defence electronics it also helps satisfy a need for improved logistics, spares, maintenance etc that can be the 'tether' for a rapid response force.
But carrying unused capability is costly both to build and to test, especially in high-integrity roles.
Software doesn't wear out. It has no need to be 'maintained' to ensure performance. Software maintenance implies removal of errors, or change to functionality, but accommodating change, economically, is heavily linked to product architecture.
Software systems are bound to their electronic platforms. These bindings can, with care, be designed to be re-mapped over life, but how do we forecast needs on a lifetime which may match that of the entire history of software system development?
What techniques should you employ; at what stage of development should those bindings be applied; and why?