Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Odlican Clanak o 1760 i 1553

Odlican Clanak o 1760 i 1553

Ratings: (0)|Views: 38 |Likes:

More info:

Categories:Types, Research
Published by: slobodan_janicijevic on Nov 13, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/13/2010

pdf

text

original

 
Safety, Software Architecture and MIL-STD-1760
Matthew John Squair
Senior Safety ConsultantJacobs AustraliaGPO Box 1976, Canberra, ACT 2601
Matthew.Squair@defence.gov.au
Abstract
Integrating modern aircraft stores, particularly weapons,creates a complex system of systems challenge. Thetraditional approach to such integrations was for each to be a stand-alone program. For each program a uniqueinterface would usually be implemented, usually alsowith a set of unique problems, such as the missile‘ghosting’ problems experienced during the F-16 toAMRAAM integration (Ward 1993). In response to the problems of such an approach
MIL-STD-1760
an
  Interface Standard for Aircraft to Store Electrical  Interconnection System
was released by the US DoD tostandardise aircraft/store interfaces. This paper discussesthe advantages and limitations of the architecturaltechniques of MIL-STD-1760. A hierarchical method for integrating the use of the standard into a safety case isalso described.
 Keywords
: Safety, architecture, software, MIL-STD-1760.
1
 
Introduction1.1
 
Architecture, bus design and integration
Unfortunately no singular agreed definition of whatconstitutes a software architecture exists, for example:“From a safety viewpoint, the software architectureis where the basic safety strategy is developed for thesoftware” (IEC 61508), or “In avionics (an architecture is) a representation of the hardware and software components of a systemand their interrelationships, considered from theviewpoint of the whole system” (STANAG 3908)ARP 4574 goes further to relate architectural design patterns to measures of connectivity (Table 1-1). For this paper architecture is defined as the large scale descriptionof system components, their interactions, connectivityand the principles and guidelines that ensure a balancedsystem design and evolution. Thus, although traditionallytypified as a protocol or ‘bus’ design issue, any decisionto select a bus protocol is also a decision that affects thecentral architectural principles of a distributed system(Rushby 2001).
Architecture design pattern Connectivity Concept
Partitioned design DecouplingDissimilar, independent designsimplementing a functionDecouplingIndependenceRedundancyActive/monitor parallel design Hot redundancyBackup parallel design Cold redundancy
Table 1-1 ARP 4754 Architecture Examples
1.2
 
Software architecture and safety
The concept of architecture is useful from a softwaresafety perspective as it can be used to impose a separationof concerns between decisions about the architecture of asoftware artifact versus the implementation. Partitioningthe design space in this way supports the development of safety arguments in a modular and hierarchical fashion.Such partitioning can also clarify organisationalinterfaces between collaborating development teams;another traditional area where safety issues can arise.Because of their abstract nature, software architecturescan also support the re-use of well understood and provenarchitectural solutions. Such re-use allows theconstruction of safety arguments based upon thecontinuity of design rather than solely upon the uniqueattributes of a specific implementation. Thus the re-use of architectural design patterns moves software engineeringcloser to traditional engineering disciplines where safetyarguments are based in large part upon the provenance of the design. Such arguments are similar to, but morearchetypal, than the ‘product service history’ argument of DO-178B (RTCA/DO-178B 1992).
1.3
 
The MIL-STD-1760 interface standard
A modern store is intended to be highly interoperable
1
 with multiple aircraft. Such a store is usually also anindependent system evolving at a pace independent of thecarriage aircraft. As such, a modern store (and its carriageaircraft) satisfies the majority of Maier’s criteria for whatconstitutes a system of systems (Maier 1996) and it is for this systems of systems domain that MIL-STD-1760 wasdeveloped.
1
Two systems are interoperable if each can conveniently benefit fromthe resources (capabilities or information) of the other.
Copyright © 2006, Australian Computer Society, Inc. This paper appeared at the
11
th
Australian Workshop on Safety Related Programmable Systems (SCS’06)
, Melbourne.Conferences in Research and Practice in InformationTechnology, Vol. 69. Tony Cant, Ed. Reproduction for academic not-for-profit purposes permitted provided this textis included.
 
 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.
2
 
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.
 
Store inventory,2.
 
Interruptive Built In Test (BIT),3.
 
Store rack unlocking,4.
 
Selective or emergency jettison firing,5.
 
Fire/release/launch sequencing,6.
 
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
2
,3.
 
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.
2
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.
3
 
Stores management systems design3.1
 
Architecture3.1.1
 
General architecture
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>>
MIL-STD-1760Mission store
<<RT/RT & BC>>
MIL-STD-1760Carriage store
<<RT>>
Store StationInterface Unit
<<RT>>
MIL-STD-1760Mission store
<<RT>>
Store StationInterface Unit
<<RT & BC>>
StoresMngtSystem
<<BC>>
MissionMngtSystem
<<RT>>
Command &Display System
Mechanical interface
S&R.E
 Aircraft discretesMechanical interface
S&R.ES&R.E
MIL-STD-1553B Stores Management BusMIL-STD-1553A/B Mission Management Bus
 Aircraft  power  Aircraft  power Dual Standby Bus
One Active Bus
Superseding Cmds
RT response to most recent command 
S&R.E = Support & Release Equipment
Mechanical interface
 Aircraft power Stores management busMission management bus
LEGEND
 Figure 3-1 A distributed stores management architecture
3.1.2
 
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
 
command/response message pair for each set of data(Sivencrona 2001)
3
.Communication protocols can be event or time-triggered,with event-triggered protocols usually applied when thereare a large numbers of discrete signals transmittingmessages in a pseudo-random or sparse time base form.Since stores management is inherently reactive and task driven in nature, event triggered protocols are obviouslywell suited to this application. Another argument for theevent driven communication protocol (adopted by MIL-STD-1760) is that time triggered protocols introduceframe delays which in turn translate to errors in weapondelivery. A final advantage is that unlike a time triggered protocol there is no need to coordinate a schedule of transmissions amongst distributed components
4
.MIL-STD-1553B is a relatively slow speed interface(1Mbps) compared to modern standards, such as FlexRaywhich runs at 10Mbps (FlexRay 2005) or Time TriggeredProtocol (TTP/C), running at 25 Mbps (TTTech 1999).However the slower bus speed does make the bus moreresistant to noise from signal reflections and ambient RFnoise.
3.2
 
Safety coordination issues3.2.1
 
The general coordination problem
Representations of data are consumed and produced byaircraft and store functions to perform the requiredmission. However, for this representational system towork, both the store and aircraft need a common first andhigher order set of 
expectations
about their own behavior as well as about the expectations and behavior of theother (Lewis 1969). Therefore, in order to coordinatesafety critical behaviour there is a need to define andmanage a common, unambiguous set of conventions (or  protocol) about the production and consumption of safetycritical data. Such conventions can also assist inconstraining the use of error prone semantic constructs.
3.2.2
 
System of systems coordination
At the system of systems level, this coordination problemtraditionally expresses itself as a problem of backwardand forward compatibility across versions of particular data formats. For example MIL-STD-1760’s definition of the Most Significant Bit (MSB) for 2’s complemententities was changed between Revision B and C thensubsequently changed back in Notice 1 of Revision C.These changes led to some developers interpreting thefirst bit as a ‘signed’ bit for a signed number while othersused a 2 complement number format. More generally theoptions introduced in successive revisions have generateda family tree of possible implementations of the standard.To further complicate matters, standards invoked byMIL-STD-1760, such as MIL-STD-1553B, havethemselves evolved over time. Other examples of 
3
In MIL-STD-1553 a 2 word command and 1 word status responsesequence consist of 32 data bits and 53 overhead protocol bits. InCANBUS a nominal message of 32 data bits has only 43 protocol bits.
4
For example by implementing a global (distributed) clock.
coordination issues at this level are the differing safetyrequirements of various weapons communities, i.e.nuclear versus non-nuclear safety.At the system of systems level, a safety argument musttherefore demonstrate that any differences betweenrevisions of the standard do not introduce hazards or if they do, these interactions are identified, excluded or controlled.
3.2.3
 
Store integration coordination
At the store integration level the coordination problemexpresses itself as false assumptions about behavior onthe other side of the interface. For example in one aircraft‘initiate battery’ commands were implemented asirreversible because traditional batteries were one shotthermal devices. However for the store being integratedthe batteries were NiCad and the command needed to bereversible. Since this was an unstated assumption of theinterface it was not identified during development, becoming evident only during integration testing. Thisexample illustrates the necessity to explicitly state all behavioural expectations and consequently drives MIL-STD-1760 to be much more than a set of data-grams.At the store integration level, a safety argument must besupported by a demonstrable claim that a common andwell understood set of data conventions are being used on both sides of the interface.
3.2.4
 
Real time distributed control
The real time and distributed control nature of storesmanagement systems also introduces the problem of howto ensure coordinated safe behaviour within such asystem. For example, launching stores from stations onone side of an aircraft can induce highly hazardousasymmetric loads, whilst simultaneously releasing storescan cause hazardous g-jump effects; both of which canlead to overstressing the aircraft. For the communications bus, this problem devolves to how to send commands in atimely, safe and reliable fashion when faced witharbitrarily long communications delays
5
over acommunications channel.At the level of real time distributed control, a safetyargument must demonstrate (expressing the problem infunctional integrity terms) that individual functions aresafe and independent, or if they do interact their coordinated behaviour is safe.
4
 
The MIL-STD-1760 standard4.1
 
The MIL-STD-1760 interface
MIL-STD-1760 defines implementation requirements for the Aircraft/Store Electrical Interconnection System(AEIS) in aircraft and stores. This interconnection system provides a common interfacing capability for stores onaircraft, and a hierarchical depiction of the:1.
 
electrical (and optical) signal interfaces,
5
For example delays from internal processing or file transfer events.

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->