MIL-STD-1760 is an open, published and non-proprietystandard intended to maximise both interoperability andsafety. While open in this sense, actual designs aretypically closed with data transfers and associateddeadlines determined during design rather than at runtime. The standard applies an architecting strategy whichis both collaborative (programs may re-use other programs efforts) and directive (by specifying minimaldesign requirements) in nature (Meyer 1998). An analogywould be a city planner enforcing a building code rather than an architect enforcing a particular design solution.As a result of this strategy, safety is an emergent attributeat both a system of systems and individual aircraft tostore integration level.
Military aircraft and weapon system safety2.1
The military aircraft domain
Military aircraft may launch or jettison stores, fly atsupersonic speeds, execute high-g manoeuvres whilstcarrying out safety critical functions including:1.
Interruptive Built In Test (BIT),3.
Store rack unlocking,4.
Selective or emergency jettison firing,5.
Arming (both immediate and preset),7.
Fuzing (both delay or mode),8.
Weapon yield selection,9.
Output stage selection (store/pylon/station), or 10.
Initiating irreversible functions (pyrotechnics).In this operational environment achieving functionalreliability is a significant technical challenge.Unfortunately achieving high reliability in thesecircumstances does not automatically equate to safety. Infact increasing reliability can decrease safety (Leveson1995), requiring us to balance the need for reliabilityagainst safety. Other challenges of this domain include:1.
limited weapon operational histories,2.
hard real time requirements
irreversible safety critical processes,4.
dynamic interface and network topologies,5.
mode rich safety critical behaviour, and6.
multiple configurations of store and platforms.To safely and reliably perform such functions aircraft andstore must coordinate their actions dictating a dependablecommunication channel robust enough to withstand theharsh operational environment.
In itself the requirement for hard real time behaviour can be achallenge to the MIL-STD-1553 data bus which has traditionally beenused for soft real time system applications.
Stores management systems design3.1
Most modern combat aircraft utilise a dedicated storesmanagement system to control stores and the support andrelease equipment associated with them. Two basicarchitectural patterns are presently used in aircraft storesmanagement systems, centralised or distributed. Acentralised architecture is generally used in situationswhere the stations to be controlled are closely located andinter-station wiring is therefore a minimal systemoverhead. Distributed architectures, as Figure 3-1illustrates, allocate stores management functions to physically separate Store Station Interface Units (SSIU)while minimising interconnects by multiplexing signalsover a data bus. Since it forms the basis of most modernstores management systems, a distributed architecturewill be used as the reference design for this paper.
<<RT/RT & BC>>
Store StationInterface Unit
Store StationInterface Unit
<<RT & BC>>
Command &Display System
Aircraft discretesMechanical interface
MIL-STD-1553B Stores Management BusMIL-STD-1553A/B Mission Management Bus
Aircraft power Aircraft power Dual Standby Bus
One Active Bus
RT response to most recent command
S&R.E = Support & Release Equipment
Aircraft power Stores management busMission management bus
Figure 3-1 A distributed stores management architecture
Communication bus protocols
MIL-STD-1760 constrains the MIL-STD-1553Bmultiplex bus communication standard to a single-master polling protocol with only one node, the Bus Controller (BC), in charge of communication on the storesmanagement bus, aw well as solving and administratingRemote Terminals (RT) access conflicts and errors thatmay arise on the bus. Due to its simplicity, this protocolmakes analysis and monitoring of communication easier than split bus control (also supported by MIL-STD-1553B). The command response structure of the protocolis well suited to reactive system application and providesa bound on latency of communications which is importantfor real time systems. Disadvantages of the protocol arethat a Single Point of Failure (SPOF) is introduced,identification of RTs during initialisation is required andcommunication overhead is increased by the need for a