AADL and MDA. Early Experience Applied to Aircraft-Weapon Integration. Yves LaCerte

Transcription

1 AADL and MDA Early Experience Applied to Aircraft-Weapon Integration Yves LaCerte 27 January 2005

2 Agenda Introduction A Weapons Management System Embedded Systems: Solutions / Trends Plug and Play Modeling Concepts Architecture Analysis and Description Language Model Driven Architecture 2

3 Introduction The aircraft-weapon integration challenge is part of a larger integration problem, i.e. Independent system-specific models often create unsolvable interoperability problems 3

4 Weapons Management Systems 4

5 POD AVAIL INV STRT TTV XMIT HI SYNC OFF ACPT TGT SLMR SONO SAFE XMIT POD CONTROL SLAM ER POST LAUNCH STA 11 STA 13 CO OP STA 14 STA 16 12/12 12/12 12/12 12/12 09/12 59:59 59:59 59:59 59:59 58:59 KILL SAFE AIMS SS - 3 FULL SCRN TOO ASUW TRCK MODE PREV TGT RJCT TGT PRE LNCH MASTER ARM BOMB BAY SRCH PWR ON OPEN ON ARM HAZARD RESET ARM HAZARD J E T T I S O N OFF KILL READY SONO DISABLE CLOSED J E T T I S O N J E T T I S O N OFF J E T T I S O N INV SONO NAVIGATION SYSTEM BIT SAFE RINU BUS BUS RINU 1 A B 2 KILL SAFE BUS BUS A B LATITUDE: N42: LATITUDE: N42: LONGITUDE: W LONGITUDE: W ALTITUDE: FT ALTITUDE: FT AIR SPEED: 295 KTS AIR SPEED: 295 KTS HEADING: 45.0 T HEADING: 45.0 T X VELOCITY: X VELOCITY: Y VELOCITY: Y VELOCITY: Z VELOCITY: Z VELOCITY: AZIMUTH: 10.0 AZIMUTH: 10.0 PITCH: PITCH: ROLL: ROLL: WANDER ANGLE: -45 WANDER ANGLE: -45 MESSAGE COUNT: 2300 MESSAGE COUNT: 3500 MESSAGE ERRORS: 1 MESSAGE ERRORS: 0 PORT TAC MSN TAP NAV RAD TMPS EO/IR CYZ A/C WIC MC SYS Definition WING ONLY Mission System Video 1553 Eth Video RINU 1553 Aircraft Discretes 1553 Eth Video Radar RS-232 RS-232 Starboard Port R A 9 R A L R A L R A R A L Starboard Wing Stations Racks 1760 ASI Legacy ASI L A R A R L A R L A R A R Weapons Bay Port Wing Stations Primary electrical, functional and logical interface between the Mission Management Computer(s), weapons, launchers and other equipment used to release and deliver stores 5

6 Motivation Today, $100M (typically)* to field a new weapon Aerodynamics 40% to 60% associated with software updates (typically)* Platform software Misc. Mission Planning System Eng. Int. & Test * Source: AFRL/MN,

7 Test and Integration Challenge Platform Perspective Provide relevant functions and data Weapon Perspective * Identify/define relevant functions and data Observe resource, performance and timing constraints Identify/define resource, performance and timing constraints Do not change platform software * Weapon software does change over time, which may impact the platform 7

8 Cost / Schedule Perspective (Notional) WMS Development Costs Number of Months to Integrate a New Weapon $ No need to take down the whole squadron New WMS Weapon 3 Weapon 3 Weapon 2 Weapon 2 Weapon 1 Weapon 1 Traditional New Traditional New Do not change platform software 8

9 State of the Art Increasing complexity / decreasing productivity six (or fewer!) lines per day * The inefficiency of the embedded software development process will prevent novel technologies from entering the marketplace in time * Typical of embedded software industry 9

10 Embedded Systems: Solutions / Trends Components Less dedication to specific functions Design - Improved abstraction Synthesis - Auto code generation Models - Assess before final implementation Specification languages Unambiguous representation of behavior and constraints - Rigorous semantics Widely accepted 10

11 Embedded Systems: Solutions / Trends Semantic Interface Specification Syntax can be performed by any type of Interface Definition Language (IDL, XML) Assess semantic properties of an interface by an executable interface model Assess interoperability by analyzing provided and required interfaces, and contracts Adapt interface to improve interoperability AADL Semantic Interface Specification 11

12 Embedded Systems: Solutions / Trends Dynamic Reflective Systems Change internal behavior depending upon attached devices Capable of integrating devices which provide new functions Capable of providing unforeseen functionality Foundation of aspect-oriented programming 12

13 Embedded Systems: Solutions / Trends Applied to Aircraft-Weapon Integration Integrate new capabilities within a given design space (domain) Prevent waiting for an aircraft upgrade cycle to integrate new weapons But Likely difficult to implement a dynamic system that meets performance constraints Aircraft-Weapon interface standards is a recent development, change is slow 13

14 The Plug and Play Concept 14

15 The Plug and Play Concept Demonstrate interoperability at design time In terms of Functionality and Data Open system approach via standards In terms of Non-Functional Quality Attributes Safety, real-time, reliability, fault tolerance, security. A system that can exchange information and services with multiple systems is more interoperable than one that can't AADL SIS Assess the quality of interoperability Formulate strategies to improve interoperability 15

16 Domain Model Weapon Interface View Platform WMS Missile Select Missile Apply power Initialize Configure Select State Set mission parameters Set missile modes etc Release Jettison Get Status IBIT Get current configuration The WMS accepts generic missile commands. These are subsequently passed on to the missile. 16

17 Domain Model Mission Interface View Platform WMS Missile Set Mission Plan Set Target Acquisition Set Platform Characteristics Set Environment Configure Configure Configure Configure The WMS offers mission services that are non-missile specific. Configuration data is subsequently passed on to the missile. 17

18 Domain Model - Life-Cycle View Start Mission Missile Selected Setup Status IBIT ON Ready Standby Identification Mission Configure Initialization IBIT OFF Ready for Release Mission Committed Non-Operational Off Release Prepare to Release Executing Mission Hung Flight Failed Disable Jettison Detonation 18

19 Domain Model - Data View Weapon Launch Acceptability Region 19

20 State Machines Preferred for the specification of controllers Remov e_operational_power Operational State Progress To Release Prepare For Release Release Useful for Of f > Apply _Operational_Power Verification against requirements Test-case generation Automatic code generation Remov e_operational_power Initialization> Error Non-Operational IBIT Control Progress to Jettison Not Running IBIT> Prepare f or Jettison> Running IBIT Jettison> API and events used to cause state changes 20

21 Ports Connectors Contracts Port Connector WMS Provided Interface Power Required Interface Weapon Component Contract <<interface>> Power 115 volts(), AC 270 v, DC 28 v, DC 1 (std) 28v, DC 2 (safety) Pre and Post conditions Parameter types Synchronization constraints QoS features 115 volts() AC 3 phase «interface» Power Weapon requires power. Power provided by WMS 21

22 Platform Challenge Component models and supporting frameworks often rely on the specifics of the underlying platform There is a need for techniques to handle functional and non-functional properties of components and systems 22

23 Non-Functional Properties External Comm Mission Planning System Laser Imaging System Generic Navigation System Fire Control System Operator I/F Weapon Management System Power_A 1553_A Discrete_A Power Controller Launcher Launcher Launcher 1553_B Power_B Discrete_B Weapon Missile Missile Architecture Analysis and Design Language (AADL) 23

24 System Example 24

25 System Construction Example system MILSystem end MILSystem ; system implementation MILSystem.MissilePlatform subcomponents connections end MILSystem.MissilePlatform ; subcomponents -- buses Power_A : bus MILPower; -- components WMS1 : system WMS.WMS; FCS : system FireControlSystem.FCS; connections -- buses bus access Power_A -> Power1.IFPower_A; bus access Power_A -> WMS1.IFPower_A; -- ports port group WMS1.Out1553_A -> Launcher1.In1553_A; 25

26 System Construction Example Black Box Port Connector WMS Provided Interface Power Required Interface Weapon Component Contract system FireControlSystem features <<interface>> Power 115 volts(), AC 270 v, DC 28 v, DC 1 (std) 28v, DC 2 (safety) IFGeneric: requires bus access MILGeneric; InMission: port group Rx_Port; OutMission: port group Tx_Port; end FireControlSystem; Pre and Post conditions Parameter types Synchronization constraints QoS features «interface» Power 115 volts() AC 3 phase system implementation FireControlSystem.FCS end FireControlSystem.FCS ; 26

27 System Construction Example Black Box system WMS features -- Buses IF1553_A: requires bus access MIL1553; IFGeneric: requires bus access MILGeneric; IFPower_A: requires bus access MILPower; IFDiscrete_A: requires bus access MILDiscrete; -- Ports port group Rx_Port In1553_A: port group Rx_Port; features Out1553_A: port group Tx_Port; Rx: in data port; InDiscrete_A: port group Rx_Port; inverse of Tx_Port OutDiscrete_A: port group Tx_Port; end Rx_Port; OutPower_A: port group Tx_Port; InMission: port group Rx_Port; port group Tx_Port OutMission: port group Tx_Port; features end WMS ; Tx: out data port; end Tx_Port; 27

28 WMS System Implementation Example Factory Pattern system implementation WMS.WMS subcomponents connections modes end WMS.WMS ; subcomponents --- processors --- processes --- bindings connections --- port groups modes MainMode: initial mode; BackupMode: mode; 28

29 Process process PlugandPlayDispatcher features InGeneric: port group Rx_Port; OutGeneric: port group Tx_Port; InLauncher: port group Rx_Port; OutLauncher: port group Tx_Port; InWeapon: port group Rx_Port; OutWeapon: port group Tx_Port; end PlugandPlayDispatcher; 29

30 Process Implementation process implementation PlugandPlayDispatcher.WMS subcomponents Bus_Listener: thread Listener.Bus_Listen; PnP_Dispatcher: thread PnPDispatcher.WMS; connections port group InGeneric -> Bus_Listener.Bus_Listener; port group Bus_Listener.Buffer_Update -> PnP_Dispatcher.InPnP; port group PnP_Dispatcher.OutLauncher -> OutLauncher; port group InLauncher -> PnP_Dispatcher.InLauncher; port group PnP_Dispatcher.OutWeapon -> OutWeapon; port group InWeapon -> PnP_Dispatcher.InWeapon; end PlugandPlayDispatcher.WMS; 30

31 Thread Producer/Consumer thread Dispatcher features Buffer_Listener: port group Rx_Port; Bus_Dispatcher: port group Tx_Port; Buffer_2: requires data access Buffer; properties Source_Text => "abc"; Source_Code_Size => 100 kb; Source_Data_Size => 10 kb; Source_Stack_Size => 10 kb; Source_Heap_Size => 10 kb; Dispatch_Protocol => periodic; Period => 100 ms; Deadline => 100 ms; Compute_Execution_Time=> 50ms; 31

32 Trade Offs Producer Consumer Event-Driven with Publish-Subscribe 32

33 Tools - OSATE Open source AADL tool environment Software Engineering Institute Set of plug-ins on top of Eclipse 33

34 Lessons Learned Model Conventions Readable Extensible Maintainable Ubiquitous Connectivity Port connections Bus interfaces Model Scale Complex coding Visualization will help Multiplicity Arrays, loops Model navigation Tree editor Compartments Ease of integrating multiple models 34

35 Future Work Use / create OSATE analysis plug-ins Schedulability System scalability Safety End-to-end flow analysis AADL support from UML vendors 35

36 Model Driven Architecture 36

37 Approach to MDA Core Reusable Corporate Assets Domain Requirements Application Requirements Platform Requirements Platform Independent Model Platform Independent Model T E Platform Specific Model C G Executable System V E Validated System Domain Application Product Instance Executable Product Validated Product TE = Transformation Engine CG = Code Generator VE = Validation Engine 37

38 Approach to MDA / AADL Derive system properties Platform Requirements UML Model C G Executable System Prove system properties Product Instance Executable Product Platform Requirements T E AADL Model C G Executable System A A D L Validated System Product Instance Executable Product Validated Product 38

39 MDA Work Products Application Requirements Context View Requirements View Platform Independent Model Analysis View Design View Platform Requirements Application Guidelines and Rules Platform Model Libraries Patterns T E Platform Specific Model Product Instance AADL Model ready for analysis UML Model ready for code generation 39

40 MDA / AADL Expectation Development Costs for New Weapons Development Costs for New Weapons $ W i t h o u t M D A New WMS $ M D A New MWS Weapon 3 Weapon 3 Weapon 2 Weapon 2 Weapon 1 Weapon 1 Traditional New Traditional New 40