Controlling the risk of COTS via application programming interfaces

There are various approaches to building critical systems. One approach is the use of fault-tolerant software architectures. This approach can be difficult even when components have been developed under a customer's control. When the detailed behaviour of the component is unknown, which is often the case with a COTS (commercial off-the-shelf) component, then providing appropriate recovery actions becomes even more difficult. To be able to tolerate erroneous behaviours, application programming interfaces (APIs) must be identified because it is through these that a component expresses its behaviour. The more information about an API that is known, the more will be known about the possible behaviours of a component and how erroneous behaviour could be tolerated. An approach to accepting safety-critical systems consisting of COTS software is the use of static analysis techniques to determine desirable properties of components. Even when a software component is analysed, the properties of that component need to be composed together with the other components to determine the overall system properties. Again, the key is to determine the APIs and how components interact through them in order to establish compositional behaviours. A COTS component tends to have more functionality than required for a particular system because it is more general-purpose. This provides more ways for unexpected behaviours to arise and threaten the integrity of a system. By identifying unwanted APIs and policing them, the extra functionality can sometimes be limited and the vulnerability of the system to failure reduced.