A Proposal for Improving Defense and Aerospace Software Quality
Standards AbstractionPlatform and system software API abstraction (as practiced by AUTOSAR) could considerably increase application lifetimes. Conversely, applications which are hardwired to their target are exposed to potential obsolescence/maintenance in the very near future. As Herb Sutter points out, the free lunch is well and truly over and extrapolating from recent success is likely to lead to extremely unrealistic expectations. Abstraction such as that provided by the AUTOSAR open architecture initiative is routed in technology (driver plug-ins) and achieving the same result through process alone is arguably infeasible. This is evident from the fact that the sonar Generic Open Architecture (see reference [6]) ends up suggesting that defense and aerospace application developers should use conditional compilation as a means of avoiding operating system lock in. We do not wish to become embroiled in technical argument here but most engineers will point out that the defense and aerospace software industry has had conditional compilation for thirty years or more, and if it were a viable alternative to platform abstraction we would still be running the sonar software we wrote thirty years ago, and clearly we are not. CLS are not acquainted with any engineers who have tried to port complex applications across operating systems using conditional compilation twice! Finer Grain InteroperabilityFor the reasons outlined in earlier sections there is a strong case for reducing the granularity of an open architecture to the point where it becomes applicable to more than one deliverable defense and aerospace sub-system. This would open up competition, reduce cost through optimal re-use, and facilitate upgrade at the algorithm level (or finer). The feasibility of this approach has already been proven by similar initiatives, and has already been practiced by existing sonar contractors who have done so purely to improve their internal efficiency. We would argue that the situation could be further improved by formalizing the architecture description and replacing paper specification with machine translatable architectural blueprints (which in turn obviates all paper interface descriptions). This proposal should not be confused with formal data description which is an area already addressed by XML. The issue here is the replacement of ad-hoc messaging with a rigorous prototype-able object oriented alternative. A full discussion is beyond the scope of this article but interested parties could find more information in references [7], [8] and [9]. Finally, we would suggest one further step that could be taken to reduce cost and risk of defense and aerospace software still further – the utilization of fine grain component libraries. Whilst this author is not naïve enough to underestimate the logistics involved in organizing MoD/DoD controlled component libraries, it is too good an opportunity to ignore. Initial investigation into the technical practicalities of identifying a core set of sonar components from which almost all sonar could be constructed has already been investigated and looks extremely promising (they all use FFTs, filters, matrix manipulation etc.). A set of guidelines for ‘general’ component identification looks feasible and could be applied to each domain of interest by respective specialists (this approach is not restricted to sonar or even defense and aerospace). When this is combined with a machine managed interfacing scheme, the drag and drop (plug ‘n’ play) approach could easily become the norm, and the potential cost/effort/risk reductions are considerable. The UK’s SSEI is an obvious vehicle for just such an initiative. Quality based AssessmentIn most industries, engineering is subjected to three constraints. Firstly, it must follow an agreed process. Software engineering follows suit with ISO9000 and other quality initiatives like CMM. Secondly, the final implementation must meet the agreed functional requirements (the house must match the plans), and again software has the notion of acceptance against agreed requirements. Thirdly however, in almost all other engineering sectors, there are universal quality standards that must be met. Foundations must be dug to certain depths, fire escapes must be provided, and structural integrity must meet rigorous conditions. In the defense and aerospace software industry by contrast, it is often the case that acceptance is based purely on demonstrable capability without any consideration of the quality of the software providing the capability. No matter how rigorously ‘process’ is followed, there is no guarantee that the final output will have met the required standards, and houses built to poor standards are known to be expensive to maintain. This is why the construction industry polices itself with independent inspection. Open architecture raises a number of issues of its own. Clearly a deliverable which locks the customer into a given contractor’s services at each technology refresh is less satisfactory than one which can be ported to the new platform by any third party. In fact this is a candidate definition for the term ‘portable’ and an obvious area for technology demonstration. Conditional compilation is an example of a solution that would almost certainly tie the customer to the contractor for the lifetime of any deliverable, and is going to be far more expensive to maintain than a truly ‘portable’ equivalent. Whilst a full discussion of this topic is again beyond the scope of this article a document is shortly to be released which proposes a metric based quality assessment scheme (see reference [10]). The scheme does not suggest that the identified metrics should necessarily be mandated for defense and aerospace projects, but instead suggests a methodical means of assessing the likely through life costs and is primarily intended for use at the bid assessment stage. Technology & MethodologyFor the reasons given in the preceding sections, we agree with the technology based approach for defense and aerospace as adopted by the AUTOSAR open architecture initiative. Although their technology is clearly not suitable for the defense and aerospace application space, we believe that the latter can be addressed in the same manner with the right technology. We confess that we are partisans in this matter and have developed a candidate technology which is described in a number of the references below. Not surprisingly, what we believe to be the requirements of an open architecture support technology, turn out be the same as those implemented for our technology. These are summarized as follows; The technology should provide a formal machine translatable language that provides a means of developing interoperable open architecture frameworks. The language should have rigorous prototyped interfaces that can automatically implement and validate all required component interfaces. The language must support all legacy interfaces (DDS, CORBA, TCP/IP etc.) and be fully interoperable with all relevant technologies (XML, web-services etc). In particular it should be object-oriented and support service oriented architectures. It should be modular, and provide fine grain component re-use. Finally, it should be intuitive enough to be understandable by all stake-holders (not just programmers) and should be machine integrate-able with mainstream UML IDEs and this favours a graphical representation. Like most languages, the candidate should have a portable runtime, but in this case it must abstract all aspects of the platform and its topology. It should also be scalable in the strict sense that it should be possible to recruit and retire slave processors at any stage of the calculation without loss of data (improving availability for mission critical defense and aerospace applications, and obviating the 50% redundancy rule). We believe that the only way to avoid obsolescence for military timescales is to be both portable and scalable. In this context we would define a portable component to be one that could run without modification on any target platform (it may need to be re-built, but it should not require code changes). By definition then, it should execute on available desktops as a single process for development/maintenance purposes, but also execute repeatably on the chosen target hardware. In the event that the runtime itself needs to be ported to a new platform, this should be achievable by any competent third party. References[1] DeRSCI Description [2] ARCI Description [3] Free lunch is over [4] AUTOSAR Commercial Initiative [5] Introduction to CLiP and its Symbolism [6] The DeRSCI Sonar Generic Open Architecture [7] Software Blueprinting [8] Infrastructure Oriented Programming [9] An OO Solution to Concurrency [10] Proposal for a Metric Based Quality Assessment scheme
|
