© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA.

© 2007 by Carnegie Mellon University MBE with AADL Course 2 Model-Based System Engineering Requirements Analysis System Integration Predictive Analysis Early In & Throughout Life Cycle Architecture Modeling & Analysis Rapid Integration Predictable Operation Upgradeability Reduced Cost ABS ETC NAV ETC

© 2007 by Carnegie Mellon University MBE with AADL Course 3 SAE Architecture Analysis & Design Language (AADL) Standard Notation for specification – task and communication architectures of Real-time, Embedded, Fault-tolerant, Secure, Safety-critical, Software- intensive systems, of hardware platforms, and deployment Fields of application: –Avionics, Automotive, Aerospace, Autonomous systems, … Based on 15 Years of DARPA funded technologies Standard approved & published Nov 2004 –approved as a standard by an international industry organization www.aadl.info

© 2007 by Carnegie Mellon University MBE with AADL Course 4 Key Elements of SAE AADL Standard Core AADL language standard –Textual & graphical, precise semantics, extensible AADL Meta model & XMI/XML standard –Model interchange & tool interoperability Error Model Annex as standardized extension –Fault/reliability modeling, hazard analysis UML 2.0 profile for AADL –Transition path for UML practitioner community using UML profile More info: http://www.aadl.infohttp://www.aadl.info

© 2007 by Carnegie Mellon University MBE with AADL Course 5 AADL: The Language Precise execution semantics for components & interactions –Thread, process, data, subprogram, system, processor, memory, bus, device Continuous control & event response processing –Data and event flow, synchronous call/return, shared access –End-to-End flow specifications Operational modes & fault tolerant configurations –Modes & mode transition Modeling of large-scale systems –Component variants, packaging of AADL models Accommodation of diverse analysis needs –Extension mechanism, standardized extensions

© 2007 by Carnegie Mellon University MBE with AADL Course 6 Model-Based Embedded System Engineering Execution Platform Devices Bus Processor HTTPS GPS Ada Runtime..... Memory DB Document the Runtime Architecture Abstract, but Precise Navigation System Airbag Deployment Parking Assistance Emission Management Cruise Control Antilock Braking System Application Software Electronic Fuel Injection System Analysis Schedulability Performance Reliability Fault Tolerance Dynamic Configurability System Construction AADL Runtime System Application Software Integration External Environment

© 2007 by Carnegie Mellon University MBE with AADL Course 7 Single Source AADL Architecture Model Schedulability analysis Latency analysis Safety analysis Reliability analysis Fault annotations Timing annotations Alternative Hardware Bindings Application Platform AADL Model Low incremental cost for additional analyses & simulations!!!

© 2007 by Carnegie Mellon University MBE with AADL Course 8 Model-based Assurance Predictive Analysis Across Perspectives Security Intrusion Integrity Confidentiality Availability & Reliability MTBF FMEA Hazard analysis Real-time Performance Execution time/ Deadline Deadlock/starvation Latency Resource Consumption Bandwidth CPU time Power consumption Data precision/ accuracy Temporal correctness Confidence Data Quality Architecture Model Reduced model validation cost due to single source model

© 2007 by Carnegie Mellon University MBE with AADL Course 9 A Control Engineer Perspective with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; K1K1 K2sK2s + - Matlab Component Analysis application Code with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; Simulink Tune parameters Continuous feedback for a control engineer Validate simulation Continuous feedback in a controller

© 2007 by Carnegie Mellon University MBE with AADL Course 10 A Software System Engineer Perspective with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; AADL Tools with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; AADL Runtime package Dispatcher is A.p1 := B.p2; Case 10ms: dispatch(a); dispatch(b); T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 234 Timing analysis Reliability analysis R1 R2 R3 R4 12 12 5 6 23 34 8 8 24 23 234 T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 234 T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 2 34 Runtime Data R1 R2 R3 R4 12 12 5 6 23 34 8 8 24 23 234 Refine properties Continuous feedback by comparing analysis results with actual results Application Components AADL-based Architecture Model Execution Platform

© 2007 by Carnegie Mellon University MBE with AADL Course 11 A Combined Perspective with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; K1K1 K2sK2s + - Matlab Component Analysis Application Code with Text_IO; package Main is begin type real is digits 14; type flag is boolean; x : real := 0.0; ready : flag := TRUE; Simulink Tune parameters Continuous interaction between Control engineer & system engineer Validate simulation AADL Tools AADL Runtime package Dispatcher is A.p1 := B.p2; Case 10ms: dispatch(a); dispatch(b); T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 234 Timing analysis Reliability analysis R1 R2 R3 R4 12 12 5 6 23 34 8 8 24 23 234 T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 234 T1 T2 T3 T4 12 12 5 6 23 34 8 8 24 23 2 34 Runtime Data R1 R2 R3 R4 12 12 5 6 23 34 8 8 24 23 234 Refine properties AADL-based Architecture Models

© 2007 by Carnegie Mellon University MBE with AADL Course 12 AADL Views Component View –Model of system composition & hierarchy –Software, execution platform, and physical components –Well-defined component interfaces Concurrency & Interaction View –Time ordering of data, messages, and events –Dynamic operational behavior –Explicit interaction paths & protocols Deployment view –Execution platform as resources –Binding of application software –Specification & analysis of runtime properties timeliness, throughput, reliability, graceful degradation, …

© 2007 by Carnegie Mellon University MBE with AADL Course 13 Predictable System Integration Through Model-Based Engineering Reduce the risks –Analyze system early and throughout life cycle –Understand system wide impact and properties –Validate assumptions across system Increase the confidence –Validate models to complement integration testing –Validate model assumptions in operational system Reduce the cost –Continuous verification and simulation helps to identify errors early –Fixing errors are easier and cheaper

© 2007 by Carnegie Mellon University MBE with AADL Course 14 Component-Based Architecture (component view) Specifies a well-formed interface All external interaction points defined as features (or ports) Multiple implementations per component type Properties to specify constrains that must be satisfied by the implementation Components organized into system hierarchy Component interaction declarations must follow system hierarchy

© 2007 by Carnegie Mellon University MBE with AADL Course 15 AADL: Components and Connections Component type component category extends features (is) subcomponents (requires) Component type component category extends features (is) subcomponents (requires) Component type identifier component category extends {component_type} features flow specification properties Component type identifier component category extends {component_type} features flow specification properties Package public component classifier private component classifier Package public component classifier private component classifier features port port group parameter access subprogram more details Component implementation identifier extends {component implementation} refines type subcomponents connections call sequences modes flow implementation & end-to-end flows properties Component implementation identifier extends {component implementation} refines type subcomponents connections call sequences modes flow implementation & end-to-end flows properties implements type Connections data event event data port group access Connections data event event data port group access is one of Properties standard user defined Properties standard user defined Property set property types property definitions property values Property set property types property definitions property values application platform composite Component Category data subprogram thread thread group process memory device processor bus system modes mode transitions mode configurations reference

© 2007 by Carnegie Mellon University MBE with AADL Course 17 software Components System: hierarchical organization of components Process: protected address space Thread group: organization of threads in processes Thread: a schedulable unit of concurrent execution Data: potentially sharable data Subprogram: callable unit of sequential code process Thread data Subprogram Thread group System

© 2007 by Carnegie Mellon University MBE with AADL Course 18 Hardware Components Processor :provides thread scheduling and execution services Memory : provides storage for data and source code Bus : provides physical connectivity between execution platform components Device : interface to external environment Processor Device Bus Memory

© 2007 by Carnegie Mellon University MBE with AADL Course 19 Open Source Tools OSATE (Open Source AADL Tool Environment) –Eclipse based –Full language support –Full AADL XMI support –Analysis plug-ins Security Latency Resource budgeting Resource allocation (Binpacker from CMU SysWeaver) Graphical AADL –Basic editor from TOPCASED –Graphical viewers by Rockwell

© 2007 by Carnegie Mellon University AADL Tutorial I-20 Platform Runtime Workspace Help Team Workbench JFace SWT Eclipse Environment Java Development Tools (JDT) Analysis Tool Via XML AADL Textual Editor AADL Parser An Open Source AADL Environment Plug-in Development Environment (PDE) Eclipse Platform Debug AADL Graphical Editor AADL Environment AADL Object API XML Document Persistence Analysis Tool Via Java Standalone Generation Tool

© 2007 by Carnegie Mellon University MBE with AADL Course 21 Benefits (Summary) Model-based embedded system engineering benefits –Analyzable architecture models drive development –Predictable runtime characteristics at different modeling fidelity –Model evolution & tool-based processing –Prediction early and throughout lifecycle –Reduced integration & maintenance effort Benefits of AADL as SAE standard –Common modeling notation across organizations –Single architecture model augmented with analysis properties –Interchange & integration of architecture models –Tool interoperability & extensible engineering environments –Aligned with UML-based engineering practices

© 2007 by Carnegie Mellon University MBE with AADL Course 22 Application Components System: hierarchical organization of components Process: protected address space Thread group: organization of threads in processes Thread: a schedulable unit of concurrent execution Data: potentially sharable data Subprogram: callable unit of sequential code process Thread data Subprogram Thread group System

© 2007 by Carnegie Mellon University MBE with AADL Course 23 System: Organize application software & execution platform into component hierarchy Separate component type (interface) and component implementations Interface specifies component features and flows Implementation defines subcomponents & connections Components have properties System

© 2007 by Carnegie Mellon University AADL Tutorial I-24 Graphical & Textual Notation system Data_Acquisition features speed_data: in data metric_speed; GPS_data: in data position_carthesian; user_input_data: in data user_input; s_control_data:out data state_control; end Data_Acquisition; speed _data user input data GPS _data Data_Acquisition s_control_data data port data type of port data port

© 2007 by Carnegie Mellon University AADL Tutorial I-25 AADL Component Interaction Flight Mgr Warnings Annunciations MFD Pilot MFD Copilot data 1553 Weapons Mgr Unidirectional data & event flow Synchronous call/return Managed shared data access

© 2007 by Carnegie Mellon University AADL Tutorial I-26 Application System & Execution Platform Flight Mgr Warnings Annunciations MFD Pilot MFD Copilot data 1553 Weapons Mgr CoPilot Display Display Processor Pilot Display Display Processor High speed network Mission Processor 1553 bus Application system binding to execution platform

© 2007 by Carnegie Mellon University MBE with AADL Course 27 Execution Platform Components Processor – provides thread scheduling and execution services Memory – provides storage for data and source code Bus – provides physical connectivity between execution platform components Device – interface to external environment Processor Device Bus Memory

© 2007 by Carnegie Mellon University MBE with AADL Course 28 Device A physical component the embedded software system interacts with Represents sensors, actuators, complex devices such as GPS, camera, engine Has physical connections to a processor via a bus Has logical connections to software components via ports device brake_pedal features brake_status: out data port bool_type; sensor_comm: requires bus access CAN_Bus; end brake_pedal; brake_pedal brake_statussensor_comm

© 2007 by Carnegie Mellon University MBE with AADL Course 29 Ports & Connections Data port out in in out Event port Event data port Port group Ports: directional transfer of data & control Data port: state, sampled data streams Event port: Queued, thread dispatch & mode switch trigger Event data port: queued messages Port group: aggregation of ports into single connection point Connection: connects ports in the direction of their flow

© 2007 by Carnegie Mellon University MBE with AADL Course 30 Port Groups Port Groups are collections of individual ports and port groups such that – a port group can be connected to individually – a component port group can be connected as a single unit Bundling of port connections reduces graphical clutter

© 2007 by Carnegie Mellon University MBE with AADL Course 31 Flow –provide the capability of specifying end-to-end flows to support end-to-end timing and latency End-to-end flows are represented by a: –flow specification – externally visible flow –flow implementation – realization of flow specification end-to-end flow declaration – –logical flow from source to destination Flows may be at any level of abstraction Can be hierarchical as necessary

© 2007 by Carnegie Mellon University MBE with AADL Course 32 Flow Specification Outside view of flow through component Flow types –Flow path from in port to out port –Flow source starts in component –Flow sink ends in component Syntax: flows F1: flow path brake -> throttle; F2: flow path brake -> tcs; Cc_system S1 flow path F1 flow path F2 throttle tcs brake

© 2007 by Carnegie Mellon University MBE with AADL Course 33 Flow Sources, Paths, Sinks device brake_pedal features brake_status: out data port bool_type; flows Flow1: flow source brake_status; end brake_pedal; system cruise_control features brake_status: in data port; throttle_setting: out data port; flows brake_flow_1: flow path brake_status -> throttle_setting; end cruise_control; device throttle_actuator Features throttle_setting: in data port float_type; flows Flow1: flow sink throttle_setting; end throttle_actuator; Brake Pedal Cruise Control Throttle Actuator

© 2007 by Carnegie Mellon University MBE with AADL Course 34 Flow Implementation Realization of flow specification Flow through subcomponents and connections Subcomponent flow in terms of its flow specification Syntax: F1: flow path pt1 -> C1 -> P2.F5 -> C3 -> P1.F7 -> C5 -> pt2 pt3 Process P1 System implementation S1.impl Process P2 C1 C5 C3 flow path F5 flow path F7 pt1 pt2 Connection

© 2007 by Carnegie Mellon University MBE with AADL Course 35 End-To-End Flow Declaration Flow of information through components from endpoint to endpoint Follows the component hierarchy Sources and destinations can be –Threads –Thread groups –Processes –Devices –Processors –Systems flow path F1 C2 C1 flow sink FS1 flow source FS1 Syntax: SenseControlActuate: end to end flow BrakePedal.FS1 -> C1 -> CruiseControl.F1 -> C2 -> ThrottleActuator.FS1; Brake Pedal Cruise Control Throttle Actuator

© 2007 by Carnegie Mellon University MBE with AADL Course 36 System Instance End-To-End Flow Flow through leaf component of system instance From a source through components to a destination Sources and destinations can be –Threads –Devices –Processors Brake Pedal Cruise Control Throttle Actuator Controller Thread Cruise Control Process System instance model

© 2007 by Carnegie Mellon University AADL Tutorial I-37 Initialized Thread Inactive Active DeactivateComplete: ActiveIn NewMode: Terminate: Dispatch: Complete: Fault: Recovered: InitializeComplete: ActiveInInitMode: InactiveInInitMode: InactiveInNewMode: ActivateComplete: FinalizeComplete: Initialize Activate Deactivate Finalize Compute Recover Repaired: Thread Execution State Machine Active Member of current mode Inactive Not member of current mode Uninitialized Inactive Terminate d suspe nd Passive state Active state

© 2007 by Carnegie Mellon University Thread properties Using properties, the detailed description of each of the execution phases can be specified: 1)Initialize allows threads to perform application specific initialization. 2)Active allows actions to restore application states between mode switches. 3)Recover allows threads to perform fault recovery actions 4)Compute represents the code to be executed on every actions. 5)Deactivate allows actions to save application states between mode switches. 6)Finalizes executes when thread is asked to terminate as part of a process unload or stop, MBE with AADL Course 38

© 2007 by Carnegie Mellon University AADL Tutorial I-39 Sample Thread Properties thread control properties -- normal execution properties Compute_Entrypoint=> “control_ep”; Compute_Excution_Time => 5 ms..10ms: Compute-Dealine=>20 ms; Dispatch_Protocol => Periodic; -- initialization excution properties Init_Entrypoint=> “Init_Control”; Init_Excution_Time => 2 ms..10ms: Init_Dealine=>10ms; end control;

© 2007 by Carnegie Mellon University MBE with AADL Course 40 Bus Processor Some Standard Properties Dispatch_Protocol => Periodic; Period => 100 ms; Compute_Deadline => value (Period); Compute_Execution_Time => 10 ms.. 20 ms; Compute_Entrypoint => “speed_control”; Source_Text => “waypoint.java”; Source_Code_Size => 12 KB; Thread_Swap_Execution_Time => 5 us.. 10 us; Clock_Jitter => 5 ps; Allowed_Message_Size => 1 KB; Propagation_Delay => 1ps.. 2ps; bus_properties::Protocols => CSMA; File containing the application code Code to be executed on dispatch Thread Protocols is a user defined property Dispatch execution properties

© 2007 by Carnegie Mellon University Analysis supported by AADL Examples of analysis supported by the AADL include –Scheduling –Throughput –Latency –Resource utilization –Error analysis –Reliability (FTA, and FMEA) In general AADL models in OSATE allows: –intermediate representation/generation of XML known as AADL-XML which can be interfaced with any analysis engine –Also, AADL-XML provides interpretability with other AADL- XML tool using Eclipse/AADL plug-ins –Or you can developed your own analysis engine using Eclipse/AADL plug-ins MBE with AADL Course 41

© 2007 by Carnegie Mellon University guideline for problem specification analysis in AADL A process for problem analysis and model development involves 1.Determine the scope of the area to investigate (e.g., context diagram) 2.Understand the system components and their functionality and quality 3.Select the required style or domain specific architecture 4.Map the functional components and data and event flows to the corresponding AADL components, connections, and flows 5.Select the required analysis engine 6.Direct the output of AADL parser to the appropriate analysis engine 7.Evaluate the result 7.1If the result is satisfactory, then you are done else go back to the step 4 and make the needed change and follow the remaining steps 42

© 2007 by Carnegie Mellon University Developing models using the AADL: AN Automotive Examples Problem Consider the following Automotive systems –Traction control system (TCS) The traction control system deals specifically with lateral (front-to- back) loss of tire to road friction during acceleration –Antilock braking system (ABS) to ensure that maximum braking is accomplished at all four wheels of the vehicle, even under adverse conditions such as skidding on rain, snow, or ice. –Stability control system (SCS) to keep the vehicle going in the direction in which the driver is steering the car. To do this, the stability control system applies the brakes to one wheel to help steer the car in the correct direction –Cruise control system (CCS) to maintain a constant vehicle velocity as determined by a driver- dictated set-point MBE with AADL Course 43

© 2007 by Carnegie Mellon University Determine the type of analysis The next step of problem analysis is to determine the perspective for analysis Embedded-RT system using software controller must address dataflow and timing issues seen by –Control engineer e.g. sampling rate –Software engineer e.g. scheduling and resource utilization MBE with AADL Course 49

© 2007 by Carnegie Mellon University determine Analysis To determine analysis type, the system (System+Application+Devices) must be fully developed. So many signal flow paths –Consult requirements to find out associated latencies –Example, we are interest in modeling of latency from the brake pedal depression to the throttle actuator How to specify the latency in number of millisecond? MBE with AADL Course 52

© 2007 by Carnegie Mellon University Case Study: Modeling the cruise control system continues on specification of traction control using AADL To develop a complete model with the right it is necessary to identify and understand the functionality of the subsystems (components) MBE with AADL Course 53

© 2007 by Carnegie Mellon University Understanding system functionality The key functionality of each control system has already being discussed Need to describe the details of cruise control system functionalities –The basic functionality of Cruise Control System (CCS) is to maintain the speed of a vehicle, over varying terrain, when the system is engaged by the driver –When the brake is applied, the system must release speed control until told to resume –Vehicle must also steadily increase/decrease the current speed when directed to do so by the driver using button (+/-) –Or by depressing/releasing the accelerator –Releasing the buttons causes the CCS to control to the last speed point. MBE with AADL Course 54

© 2007 by Carnegie Mellon University Mapping to the AADL Having identified the components and their functionality, we can begin Step 4 of the problem analysis and modeling in AADL –Using AADL, model development can be done Top-down Bottom up Combined approach –We develop CCS in AADL using top-down approach Create top level (high level view) of CCS in AADL Specify/refine each element of high level model The software component part of the model will be fully refined (implemented) The hardware component part of the model will be fully refined/ specified (implemented) The software will then be bound to the hardware to represent the composite system MBE with AADL Course 58

© 2007 by Carnegie Mellon University Methodological issue Solutions to the cruise control design can be including –the data-flow approach [Wang 89]; –the procedure-call approach, [Ward 87]; –the object-oriented programming approach [Booch 86, Ward 84]; –the state-based approach – feedback-control models [Shaw 95]. Deciding which design methodology should be used to solve real-time control problems is difficult due to the complexity of interrelated issues. The focus here is to show how the AADL is used once a method is chosen –the procedure-call method is used (global state) MBE with AADL Course 64

© 2007 by Carnegie Mellon University Analysis: Flow Analysis AADL can be used to model both data and control flows A flow specifies the flow of data/event through multiple components a long a sequences of components and connectors Components (e.g., thread/process/system) has a flow specification as part of its component type declaration The main purpose of providing flow specifications is to support many form of end-to-end analysis –Completely through the system –Or within a subset of components MBE with AADL Course 71

© 2007 by Carnegie Mellon University Analysis: Flow Analysis (2) The analysis include –End-to-end timing and latency –Numerical error propagation –Processing sequences of domain objects –Quality-of-service resource mgt based on operational modes To perform these analysis, need –To specify relevant properties such as ports, flow specification, and flow-specific properties E.g., a flow-specific property could be the expected max latency that the data within a component would experience, as well as the actual latency MBE with AADL Course 72

© 2007 by Carnegie Mellon University Developing the system implementation At this point, a top-level model of CCS has been developed –Using decomposition and refinement, each subsystem has been refined to the lowest level –Connection among the system/subsystems have been developed –System flows have been defined and specification based analysis has been discussed –To complete the model, need to show how binding to hardware occur how system implementation are model based on the declarations how connections are made for a specific implementation, how flow implementation can be specified to show a complete flow analysis MBE with AADL Course 76

© 2007 by Carnegie Mellon University Binding to a Computing Platform AADL supports modeling of HW of the target system Binding the software components to the corresponding HW components allows the modeler to specify and evaluate the interactive efforts of the complete system –E.g., evaluating system software on a uniprocessor system vs. a distributed parallel processor system MBE with AADL Course 77

© 2007 by Carnegie Mellon University More on binding The other advantage of this modeling approach is the ability to test and evaluate the system for problems that occur due to concurrency issues –E.g., access order to variables, deadlock, livelock, etc) that could surface These problem generally not exposed until late in the software development (i.e., actual integration) Using AALD, software application can be mapped onto any number of processors (HW) –Help to ensure that the actual implementation is consistent with the specified target processor Multiple processor may be specified and application distributed among them MBE with AADL Course 78

© 2007 by Carnegie Mellon University Development of HW or system component To complete the HW-component declarations, a system component must be declared that will eventually hold the HW components system cc-computer -- a declaration for cc-computer to be composed of processor, memory -- and bus in its implementation --Needs to provide bus access so the devices in cc_application can -- they communicate with cpu --Devices need to attached to a bus Features –Devices_bus: provides bus access PC104ISA_16BIT; // i.e., system provides bus connections to // devices end CC-computer MBE with AADL Course 85

© 2007 by Carnegie Mellon University Example: Train System Controller MBE with AADL Course 93 What can be read out of this figure is that the data flows from the door sensor and button into the control system and from there data is sent to the actuator.

© 2007 by Carnegie Mellon University Annex Using annexes, AADL can be extended with new features and additions If a particular organization needs a special kind of feature no yet available in AADL they can develop their own implementation/specification annex. Currently four annexes have been verified and added to the AADL standard –the error model annex, –graphical AADL notation annex, –programming language compliance and API annex –XML/XMI Interchange Format Annex –Behavioral annex used to analyze deadlock/livelock, etc MBE with AADL Course 95

© 2007 by Carnegie Mellon University OSATE (Open Source ADL Tool Set) OSATE is build on top of eclipse and is mainly a development and type checking tool supporting some analysis tools. With TOPCASED-OSATE also has graphical design properties. –TOPCASED is an independent open source project that focuses on making graphical editors for several system engineering standards. MBE with AADL Course 97

© 2007 by Carnegie Mellon University AADL Tutorial I-98 AADL and Scheduling AADL provides precise dispatch & communication semantics via hybrid automata AADL task & communication abstraction does not prescribe scheduling protocols –Cyclic executive can be supported Specific scheduling protocols may require additional properties Predefined properties support rate-monotonic fixed priority preemptive scheduling This scheduling protocol is analyzable, requires small runtime footprint, provides flexible runtime architecture

© 2007 by Carnegie Mellon University AADL Tutorial I-99 Faults and Modes AADL provides a fault handling framework with precisely defined actions AADL supports runtime changes to task & communication configurations AADL defines timing semantics for task coordination on mode switching AADL supports specification of mode transition actions System initialization & termination are explicitly modeled

© 2007 by Carnegie Mellon University AADL Tutorial I-100 Behavior Modeling Operational modes (in core AADL) End-to-end flows (in core AADL) Error models & reliability analysis (extension) Lacks behavioral modeling capabilities –It can be added to address a range of behavioral analyses not provided by core language State reachability Flow traceability Protocol verification Model checking

© 2007 by Carnegie Mellon University AADL Tutorial I-101 AADL Version 2 Research Ideas 1. Dynamic Reconfigurable Real-Time Fault-Tolerant Asynchronous Architectures 2. Additional trackable automated modeling and analysis methods for architectural specs (composition, pattern recognition to reduce state space) 3. Rigorous links/relations between multiple engineering modeling approaches – Simulink/VHDL – AADL, SDL – AADL, compositional scheduling 4. Architectural verification -(is the Architecture spec correct and do components comply with their specs, stronger plug and play ) 5. Mode transition modeling, state space reduction for mode analysis/scheduling 6. Modeling of specific system building approaches/patterns – example RT CORBA that can be applied as abstractions at a higher level but used to generate an implementation. 7. Modeling sublanguages and properties to support special areas of analysis for high integrity systems – Current Error modeling annex, safety and security annex, component behavior annex etc.

© 2007 by Carnegie Mellon University AADL Tutorial I-102 AADL Status Requirements document SAE ARD 5296 –Input from aerospace industry –Balloted and approved in 2000 SAE AADL document SAE AS 5506 –Core language: In ballot April 2004, July availability –UML profile, XML schema, Error Model Annex, Ada and C Annex in review, to be balloted in June 2004 Version V.2.1 September 2012

© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA.

Similar presentations

Presentation on theme: "© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA.

Similar presentations

Presentation on theme: "© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA."— Presentation transcript:

Similar presentations

About project

Feedback