Modelling Avionics Architectures

Transcription

1 Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 ESA UNCLASSIFIED For Official Use

2 Rationale 1. System architectures don t differ significantly a. One OBC that communicate with devices through a bus b. Few variabilities, impact only some components c. Components reuse, avoid costly new components 2. but a single error can have a major impact! a. During design (Mars Climate Orbiter) or implementation (Ariane V) b. Must validate components integration c. and automate system production Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 2 2

3 Proposed Approach 1. Define mission criteria a. Max weight, orbit position, duration, etc. 2. Specify functional aspects a. What will be provided by the platform b. Specify requirements & constraints Leve el of details Functions Planned implementation 3. Refine the architecture a. Replace functions by implementation Mission criteria b. Reuse existing components 4. Validate planned implementation a. Implementation properties vs. Function requirements b. Automate system integration verification Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 3 3

4 Proposed approach, cont d Step 1 Step 2 Functional architecture (functions and their interactions) Refinement with generic building blocks Mission requirements (duration, mass, etc.) Implementation (processor, bus to be used) Update models Validation KO Automatic validation of mission requirements Validation OK Step 3 Criteria and/or architecture modification Build & implement the system Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 4 4

5 Modelling mission criteria & system functions 1. Mission criteria defined in the root system component a. One criteria = one AADL property 2. Functions with AADL abstract or system components a. Abstract components: replaced later by a component category b. System components: implementation will be a sub-system 3. Define buses to be used and connected between functions a. Use a generic AADL bus component b. Bus accesses (one or several) on functions c. Specify buses requirements (generic bus instance) d. Describe connections constraints (bus accesses on functions components) On-Board Computer Telecomand & Telemetry Mass Memory AOCS Communication bus Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 5 5

6 Functional architecture textual AADL abstract fobc busaccess : requires bus access genericbus; properties Capacity => 1000 MIPS; Weight => 1Kg; end fobc; Mission requirements system fakemission properties Memory => 1Gbytes; Weight => 20 Kg; Power => 300W; end fakemission; abstract ftctm busaccess : requires bus access ; properties Weight => ; end ftctm; system implementation fakemission.i subcomponents aocs : abstract faocs; mem : abstract fmemory; tctm : abstract ftctm; obc : abstract fobc; bus : bus genericbus; connections bus access aocs.busaccess -> bus; bus access mem.busaccess -> bus; end fakemission; abstract fmemory busaccess : requires bus access genericbus; properties Memory => 1 Gbytes; Weight => 500g; end fmemory; abstract faocs busaccess : requires bus access genericbus; properties Weight => 13Kg; end faocs; On-Board Computer Telecomand & Telemetry Mass Memory AOCS Communication bus Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 6 6

7 From functional to implementation architecture 1. Replace abstract components a. Reuse existing components from a library b. Refines main system sub-components c. Use component category or sub-systems 2. Specify bus to be used a. Modify bus bindings b. Describe connections constraints Function 1 Function 2 Sensor Architecture refinement Functional bus 1553 bus Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 7 7

8 From functional to implementation architecture abstract function1 ba : requires bus access genericbus; end function1; system obc ba : requires bus access bus1553; end obc; device sensor ba : requires bus access bus1553; end sensor; system implementation mission.i subcomponents f1 : abstract function1; f2 : abstract function2; b : bus genericbus; connections bus access f1.ba -> b; bus access f2.ba -> b; end mission.i; system implementation mission.planned extends mission.i subcomponents f1 : refined to system obc; f2 : refined to device sensor; bus : refined to bus1553; end mission.i; Function 1 Function 2 Functional bus Architecture refinement OBC 1553 bus Sensor Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 8 8

9 Designing generic building blocks 1. Rely on prototype functionality from AADLv2 2. Define generic components a. Specialized with studied variabilities (mainly bus accesses) device generic_sensor prototypes bustype : requires bus access; ba : requires bus access bustype; end generic_sensor; Access to a spacewire bus Sensor with spw support device sensorspw extends generic_sensor (bustype => requires bus access spacewire) end sensorspw; Generic Sensor Access to a generic bus Sensor with 1553 support Access to a 1553 bus device sensor1553 extends generic_sensor (bustype => requires bus access 1553) end sensor1553; Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 9 9

10 Validation Implementation compliance with mission criteria a. Impact of non-functional properties b. Validate requirements not defined in the functional architecture Implementation Mission criteria Validation Functional compliance with mission criteria a. Earlier validation b. Check high-level requirements Functional architecture Implementation compliance with functional architecture a. Low-level vs. high-level requirements b. Impact between functional and non-functional properties Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 10 10

11 Issues with the AADL language 1. Components refinement & bus access a. Features & refined components b. Redefinition of in the instance model 2. Prototypes a. Support of prototype for bus access b. Prototype support by current tools c. More example required 3. Arrays a. Arrays & prototypes (define the type of an array using prototype) b. Potential array redefinition (redefine array size) Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 11 11

12 Tool support for graphical modelling 1. Support for textual representation a. OSATE2 still in beta/alpha b. Ocarina support for AADLv2 still incomplete 2. Limited integration of graphical notation a. Limitations of actual tools for industrial use b. Partial export to textual AADL 3. Real need of tool support a. User-friendly interface b. Integration of all AADL mechanisms (extensions, prototypes, etc.) Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 12 12

13 AADL models validation support 1. Requirements Enforcement Analysis Language a. Properties and instance model validation b. Strong limitations for industrial use c. Not user-friendly, need front-end to be used 2. Equation/Constraints annex? a. Potential standardized validation language b. Inheritance with REAL? Industrial support? 3. Tool support a. OSATE2 plug-in? b. Ocarina, extension of REAL? Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 13 13

14 Conclusion 1. Iterative process to model system architecture a. Model first system functions b. Refines to the hardware & run-time architecture 2. AADL language concerns a. Components refinements & prototypes b. Validation language 3. Tool support a. Graphical modelling front-end b. Validation language support Modelling Avionics Architectures Julien Delange Hollywood, Florida 24/01/2011 Slide 14 14

15 Questions? ESA UNCLASSIFIED For Official Use