Model-Based Development of ARINC 653 Using UML and Sysml Andreas Korff, Atego – OMG RT Workshop, Paris, 18.04.2012

Model-based development of ARINC 653 using UML and SysML Andreas Korff, Atego – OMG RT Workshop, Paris, 18.04.2012

 Motivation of Integrated Modular Systems

 Modelling Notation Standards UML and SysML

 Applying UML and SysML to IMS

 ARINC 653

 Using Models to support ARINC 653

 Conclusion

Integrated Modular Systems (or IMA) aim to

 Minimize Life Cycle Costs

 Enhance Mission and Operational Performance

 Allow greater flexibility and re-use in Development and Maintenance

Existing standards for IMS

 ARINC 653 – for implementing IMS concepts onto RTOSes

 Stanag 4626/EN 4660 – to de-couple Avionics HW and SW

Broad range of possible problems:

 Any failure effects everything

 Scheduling sensitive to any change

 Difficult to maintain:

Obsolecence

One change effects again everything

 Re-Use?

 On Closer inspection, logical ‘wrappers’ appear that perform specific functions.  These can be interpreted as ‘layers’ in a Federated Architecture

Physical Interface Layer Central Data Formatting Layer Controller Data Processing Layer

 In an IMS layered architecture each layer has a clearly defined responsibility, interface and is as important as each of the other layers

Federated Architecture Stanag 4626/EN 4660 (ASAAC) {maps for logic} Data Processing Layer Application Layer

{maps for scheduling}

{maps}

Data Formating Layer Operating System Layer

Physical Interface Lacer Module Support Layer

 The Application Layer is partitioned into a network of (potentially) reusable components.  Each component has a secure execution environment (processor time and memory).  Inter-component communication is managed by the OSL.  All components are loaded into memory and scheduled by the OSL.  A set of components can be re-configured at run-time

 A set of components execute on a specific hardware node.  A complete system will require a number of hardware nodes.  The OSL (across all the hardware nodes) manages and co-ordinates the system.

 The allocation of components to hardware nodes is not static at run-time.

The failure of a critical component on one hardware node will cause it to be re- deployed to another hardware node.

The failure of one Hardware Node will cause all components to be re-deployed.

 Changes in Mission may also cause a reconfiguration.

 The OSL must know: What component is running Where the component is running How long the component runs for What to do if the component fails Scheduling policy for all components Information required by all components Information provided by all components …  All this information is held in ‘Blueprints’ Software (for each component) Hardware (for each hardware execution environment) Configuration (links Software with Hardware) Run-time (contains multiple configurations)

 Keep breaking the problem down until you have solved all the parts…

 Is the whole the sum of all the parts?

Context Diagram  Design notation cannot be extended to (DFD 0) capture essential properties (e.g. thread execution parameters).

 The hierarchy becomes almost immutable!

 Complexity becomes hidden in the DFD X hierarchy!

DFD X.Y

 The nodes (data/control transforms) are (relatively) easy to maintain (i.e. changes 1 Flow Change localised to a node).

 Information flows that link nodes are NOT easy to maintain! The knock-on 3 Flow Changes effects caused by the introduction of the hierarchy can be prohibitive.

12 Flow Changes

 Unless a rigorous maintenance process is adopted, it is often quicker (i.e. cheaper) to implement a change only where the design is significantly affected.

 The higher-levels of the hierarchy become almost obsolete or overlooked.

 Information-flows at high- levels connect DFD’s at low- levels.

 Design information on High- level DFD’s become an integral part of the network.

 The hierarchy flattens into a network of collaborating nodes.

 Hierarchical design notations are deficient in detailing the distributed nature of IMS modules.

 Limited (if any) extensibility to capture specific IMS properties.

 A notation capable to handle networks of generic elements is needed

=> UML (and SysML)!

AEach model diagram contains-type artefacts provides a andunique interrelationships perspective or between artefacts.viewpoint on an underlying model.

Model

The Software Pilot Data Entry Panel :The Software

Pilot Presses Key Key Press Software Determines new Mode Key Press( KEY ID ) if NAV Key then Enter Navigation Mode Stores Set Mode( NAV ) Navigation Data elsif Weapons Key then case Selected Store is when Loft Bombs => Set Mode( LOFT ) Deploys when Retard Bombs => Set Mode( RETARD ) Weapon Pilot when Guns => Set Mode( GUN ) when Rockets => Set Mode( ROCKET ) end case Performs end if Sorte

Use Case Model Scenario Model (Modelling capabilities of each IMS layer) (Detailing communication flows between IMS components)

::Product ::Service

«Create»/ Item Type {Exclusive} «Destroy»/ ::Work Instruction running down Description stopped Entry/monitor.inhibit(LOP); after( 40s )/ Start Date valve[vent].open...; timer.set(40); 1 Describes Work On 1..* ::Revenue Item start compressor/ motor.stop; Duration valve[inlet].close; Performance Rating Cost valve[outlet].close; Agree Performance Rating 1..* 1..* [!monitor.check(LOP)]/ valve[by-pass].open; ... monitor.activate(LOP) * Markets Manages Purchases stop compressor/ timer.cancel(30); 1..* Worker 1 Manufacturer 1 Customer [monitor.check(LOP)]/ timer.cancel(40); 1 ::Person 1..* Works For 1 ::Company Manager Employee Employer Name Name stop compressor/ Age 1 waiting for oil pressure to build Assign Entry/monitor.inhibit(LOP); Un-Assign valve[vent].close; 1 1 Supervisor Updates timer.set(30); stop compressor/ timer.set(40); timer.cancel(40); 0..1 motor.start; ... 1..* 1 ::Contract ::Contractual Constraint ::Development Plan 1 * timeup/ Start Date Description monitor.enable(LOP) Mean Performance * Salary Update Training Needs Updates Grade Current Skills Change Grade

operating waiting for gas pressure to build after( 10s )/ Constraint Type {Inclusive} valve[by-pass].close; valve[inlet].open; valve[outlet].open; ... ::Term ::Condition

Dynamic Model Class Model (Detailing dynamic behaviour of IMS components) (Detailing static architecture of IMS components)

 SysML & UML can be extended by «Stereotypes» Stereotypes are applied to standard UML model-elements. Additional properties (“Tags Definitions”) are added to stereotypes.  SysML & UML can encompass any language domain: Software Engineering − Programming Languages (e.g. Ada, Java, C, C++, C#, IDL, VB) − Real-time Systems (OMG MARTE Profile) − Component-based Development − Incremental Development Systems Engineering − IMS Terminology (Stanag 4626/EN 4660 & ARINC-653) − Business Terminology − System On Chip (OMG SoC Profile) − Architecture Analysis & Design Language (SAE AADL Profile) − Goal Structured Notation (GSN) − Architectural Frameworks – Zachman – UPDM (MODAF/DoDAF) − AUTOSAR − … © 2011 Atego. All Rights Reserved. 23 Extensibility – What is a Stereotype?

 A stereotype defines how an existing metaclass (UML model-element type) may be extended, and enables the use of platform or domain specific terminology or notation in addition to the ones used for the extended metaclass.  A stereotype can be used to change the semantics of a model element in an non-arbitrary way.

 Tag Definitions allow additional properties (of the Stereotype) to be documented.

For example, RMS Voltage, Peak Voltage, Current …

Create the ARINC 653 Elements (cross referencing with other UML model-elements)

It’s all UML under the cover!

 An “IMS Profile” encompasses the terminology of IMS.

Properties (WCET, Scheduling policy, memory requirements…) are tags within the IMS Profile.

 These properties are available outside of the model (via XMI/XML for example) for assessment and analysis (because the profile makes these properties a formal part of the modelling language).

Safety assessment, performance analysis etc.

Module Support Layer

Module/OS Interface

Operating System Layer

AP/OS Interface

Application Layer

«include» Power Up Continuous Warm Built-In Test  Each layer in the

Power Up Cold «Primary Actor» architecture provides «Primary Actor» Time «include» Power «include» Power Up ‘capabilities’.

Power Up Built-In Test

See Store Information Use Case Diagram «include» «Primary Actor»  These can be documented Pilot Shutdown Store «include» Information as Use Cases. «include»

Execute Mission «include»

Communicate  Use Cases can be Load Mission «Secondary Actor» Mission Plan hierarchically organised.

See Execute Mission Use Case Diagram

«Secondary Actor» «Primary Actor» «Primary Actor» Application Layer Commander Navigator Bombadier

Hazard Analysis: What if something goes wrong?

Land Aircraft Description Pilot Navigator «Single Press Button» «Equipment» «Display Surface» «Display Surface» Navigator VOR ILS «Singleton» «Singleton» «Singleton» VOR/ILS VOR ILS Head Up (Front) Head Up (Rear) «Controller» «Controller» TheVORILS Format Manager ILS Manager :Logical::VOR ILS Here :Formats::Format Manager :ILS::ILS Manager Initiate ILS Landing Sequence The Pilot informs the Navigator to initiate a landing sequence

The Navigator selects ILS Select ILS The VOR ILS (Subsystem) receives Toggle VORILS Mode the request to enter ILS. Or Here The VOR ILS (Subsystem) informs the Enter ILS VOR ILS (Equipment) to enter ILS Timeout Required? mode. Or Here while ILS Not Active loop

Retrieve the State of the VOR ILS Get State (Equipment) Or Here end loop

VOR ILS informs the Format Manager Activate Format( ILS Format ) to Display the ILS Format

Activate the Head Up (Front) Activate( ILS Format ) (Display) with the ILS Format

Activate the Head Up (Rear) (Display) Activate( ILS Format ) Or Here with the ILS Format

Activate the ILS Manager Activate while ILS Active loop Schedule the ILS Manager Schedule Retrieve the Raw Localiser Data Raw Localiser Retrieve the Raw Glideslope Data Raw Glideslope Retrieve the calculated Localiser Get Localiser Sym Position position Or Here Retrieve the calculated Glideslope Get Glideslope Sym Position position

Update the Head Up (Front) Update( ILS Symbology ) (Display)

Update the Head Up (Rear) Update( ILS Symbology ) (Display) Land Aircraft (System Only) Land Aircraft (Software Only)... end loop

 A clear understanding of dynamic behaviour is essential.

 UML allows the dynamic properties of the whole IMS, an individual IMS component or an individual thread (within a process) to be linked with the IMS structure. Application 1 Process 1 1 1 Thread 1

«C reate»/

Suspended Abstract Thread The behavioural {Abstract} Stop Thread/ Stop Thread/ Dormant Ge My Thread ID () characteristics of an Get Thread Ststus () S tart Thread/ Lock Thread Preemption () individual thread. Sleep () when[Timeout Expired]/ Extra properties Ready Waiting Sleep Until () when[Semaphore Released]/ Start Thread () such as scheduling Stop Thread () S le e p / Suspend Self () Sleep Until/ policy (e.g. priority S us pend S elf/ Terminate Self () when[Suspended]/ W ait For Sem aphore/ Unlock Thread Preemption () Receive Message/ inheritance, priority Running Wait For Semaphore () when[Scheduled]/ Receive Message () ceiling) can be added Term inate S elf/ «use» «use» «use» to the overall dynamic Terminating «Des troy »/ ::ASAAC::APOS::Thread Management model and analysed. ::ASAAC::APOS::Communication

::ASAAC::APOS::Synchronisation

APOS Thread Management File Handling Error Handling

Sleep () Create Directory () Log Message () Sleep Until () Delete Directory () Raise Application Error () Ge My Thread ID () Create File () Get Error Information () Start Thread () Delete File () Terminate Error Handler () Suspend Self () Open File () Stop Thread () Close File ()  The (Stanag 4626/EN 4660 ) Terminate Self () Lock File () Lock Thread Preemption () Unlock File () Unlock Thread Preemption () Get File Attributes () Application/OS interface Get Thread Ststus () Seek File () Read File () Time Management Write File () captured as a set of class- Get Absolute Local Time () Get File Buffer () Get Absolute Global Time () Release File Buffer () Get Relative Local Time () Synchronisation partitioned operations. Power Conversion Create Semaphore () Set Power Switch () Delete Semaphore () Reset Power Switch () Wait For Semaphore ()  The run-time characteristics of Get Power Switch Status () Post Semaphore () Get Semaphore Status () Communication Get Semaphore ID () each operation are captured as Send Message Non Blocking () Create Event () Receive Message Non Blocking () Delete Event () Send Message () Set Event () IMS properties. Receive Message () Reset Event () Lock Buffer () Wait For Event () Send Buffer () Get Event Status () Receive Buffer () Get Event ID () Unlock Buffer () Wait On Multi Channel ()

Debugging

Get Debug Error Information ()

 An individual Processing Node (execution environment) External Connections (Port) Boards (Part) Data Bus (Part) Memory (Part)

 Topology of all Processing Nodes.

Details (on previous slide) reside in the model, only the top-most part is required here.

 Standard, supporting IMS  Aerospace and beyond  Strong partitioning between applications leads to:  System robustness  Reuse Application in different configurations Certification where Application changes context Decreased recertification costs (improved change isolation)  Reduce cost of over-certifying lower SIL applications Isolate them from higher SIL applications using partitioning  Reduce cost of re-certifying unchanged applications Where applications in other partitions have changed

 Openly integrated with RTOS and IDE’s Supporting ARINC 653  APEX Applications make calls to the Application Executive defined by ARINC 653 to decouple the applications from vendor ARINC 653 implementations  Primarily Text Entry Application behavior and initialization is coded in programming languages (Ada, C, etc) System configuration is coded in XML files (ARINC 653 concepts such as partitions, ports, channels etc)

 Synergistic advantages

Ease of Adoption

Clearer Workflow

Communication

Productivity

Link between configuration and applications clearer in single model

 Possibility to automate and re-use model-based software engineering techniques

 Create all necessary elements based on pre-configured templates

 Module, Partition, Application, Process, Port, Channel

Artisan Studio Model

«Module» BallGameModule BallGameModule «SystemHMTable» «ModuleHMTable» «PartitionHMTable» «SharedLibrary» Description 1..* systemHm : moduleHm : partHm : vxSysLib : : Configuration Detail «Partition Part» «Partition Part» «Process» : Application Detail Player1Partition Player2Partition Player1

loop «ScheduleWindow» {ReleasePoint, DurationSeconds = 0.25} MsgReceived : char «Partition Part» «Partition Part» Player1Partition : Player1Partition Player2Partition : Player2Partition seq entrypoint ()

«QueuingPort» «QueuingPort» Player1 () «Application Part» «Channel» «Application Part» seq QueuingPort1 QueuingPort2 Player1Application : Channel1 Player2Application : Player2Application RxMsg (in PortID : QUEUING_PORT_ID_TYPE) : int Player1Application end loop «ScheduleWindow» {ReleasePoint, DurationSeconds = 0.25} DisplayReceivedMsg () «Process Part» «Process Part» «Channel» Player2 : Player2 TxMsg (in PortID : QUEUING_PORT_ID_TYPE, inout Msg : char) Player1 : Player1 Channel2 Print (inout Text : char) «QueuingPort» «QueuingPort» QueuingPort2 QueuingPort1 After (in Time : SYSTEM_TIME_TYPE) : int

Artisan ACS VxWorks653 Apex Generator Artisan ACS C VxWorks653 Production Generator Wind River Workbench Workspace

: Configuration Project : Application Project 1..*

: Configuration XML Files 2..* : Initialization Source Files 2 : Source Files 2..*

Wind River Build System

Binary or Binaries for Target or Simulator

 (Open) Ergonomic UML Profile containing

all ARINC 653 views and elements

Automation Scripts to ease auto-generation of necessary elements

 Code Generators (and Generator Models) to get

ARINC 653 Configuration Files (XML)

Startup Code for the selected RTOS supporting ARINC 653

 Professional Services to adapt

Profile Scripts

ARINC 653 Generator Models

Description You Me :Attendee :Speaker {Speech Time} 1 loop while open questions exist 1.1 Question Question 1.1.1 Answer Answer end loop