March ASSERT WP4.2 – Framework Development Experiment Main FwDE Activities Domain Analysis Objective: Characterize the functionalities to be covered by the FwDE Baseline Tools: XFeature Expected Output: feature model for FwDE PlM Component View Objective: Define the functional interfaces for the FwDE building blocks Baseline Tools: Rhapsody Expected Output: UML Component Model Functional Verification Objective: Define and verify functional properties for the PIM (optional activity owing to uncertainty over tool support) Baseline Tools: TBD (HRT-UML or IF) Expected Output: Verified Functional Properties PlM Behavioural View Objective: Define the functional behavioural specification for the FwDE building blocks Baseline Tools: Rhapsody Expected Output: UML State Chart Model Domain Design Objective: Map the PIM to the RT Java Platform Baseline Tools: Rhapsody Expected Output: UML Class Model PSM Class View PSM Timing View Domain Implementation Objective: Impose the Ravenscar Computation Model upon the PIM Baseline Tools: HRT-UML (TBC) Expected Output: HRT-UML Class Model Result Evaluation Objective: Evaluate results of FwDE Baseline Tools: n.a. Expected Output: technical note PSM Code Gen. Objective: Generate code for PSM (only part of the code is covered) Baseline Tools: Rhapsody Expected Output: Source Code N.B. Activities within the same box are not necessarily done in the order in which they are shown

March ASSERT WP4.2 – Framework Development Experiment Cyclical Telemetry Concept TmStream AppComp TmManager PUS Application Process TM packets are loaded and unloaded into the TmManager by application components The TmManager is responsible for managing the list of pending TM packets and periodically asking them to update themselves and serialize themselves to a TmStream TmFactory The TmFactory returns unconfigured TM packet components Each TmManager is associated to a TmStream Terminated TM packets are returned to the TmFactory TmRegistry filters TM packets

March ASSERT WP4.2 – Framework Development Experiment FW Adaptation Process Framework Software Component Framework-level Properties capturing domain-invariant behaviour and functionalities Framework-level Properties (inherited from framework component) + Application-level Properties capturing application-specific behaviour and functionalities (introduced by adaptation process) Adaptation Process Application Software Component

March ASSERT WP4.2 – Framework Development Experiment Framework -Based Process Domain Model Design Pattern Model Component View Class View Timing View Platform-Independent Model Formal Verification Domain Design PhaseDomain Implementation PhaseDomain Analysis Phase Objective: Define the domain to be covered by the framework Technology : Feature Modelling Tool : XFeature (from Task 4.2.3) Objective: Define non-functional characteristics of FW components Technology : HRT-UML Tool : HRT-UML Tool (Task 4.2.1) Objective: Define functional interfaces of the framework Technology : UML2 Tool : UML2 Eclipse Plug-In Objective: Verify functional properties exported by the framework Technology : Design-By-Contract Tool : See WP4.3 Objective: Define functional behaviour of FW components Technology : State-Charts Tool : UML2 Eclipse Plug-In Objective: Describe design solutions Technology : Design Patterns Tool : None (follow GoF standard) Objective: Define code generators for framework component models Technology : Code Generation Tool : JET Eclipse Framework Objective: Define residual part of FW component implementation Technology : Ada/C/C++/Java Tool : SW Development Tool Platform-Specific Model Code Generator Manual Coding

March ASSERT WP4.2 – Framework Development Experiment Family-Based Process Domain Analysis Domain Needs Domain Design Domain Model Domain Implementati on Requir. Definition Application Needs Adaptation of Family Assets Integratio n & Testing Family Creation Process Family Instantiation Process Domain Model Application Family Assets Non-Family Building Blocks Asset Models

Page 6 Shared Properties NB: Formal verification activities are outside the scope of CORDET! Shared Properties Domain Dictionary Shared properties are expressed in natural language in terms of entries in the domain dictionary Design Entities Shared properties and domain dictionary entries are mapped to design entities in the domain design Map from domain analysis to domain design level LFormulas (TBC) Verification Models Shared properties are expressed in terms of a verification language (out of scope of CORDET) Domain Design Domain Models Design Models Domain Analysis Logical Formulas Verification Models

Page 7 Shared Properties NB: Formal verification activities are outside the scope of CORDET! Shared Properties Domain Dictionary Shared properties are expressed in natural language in terms of entries in the domain dictionary A. - G. Contracts UML2 Model Elements Shared properties are mapped to assume-guarantee contracts defined on the UML2 design models Logical Formulas Verification Models Shared properties are expressed in terms of a verification language (out of scope of CORDET) Domain Design Domain Models Design Models Domain Analysis

Page 8 Domain Model Shared Properties Domain Dictionary Captures invariants in natural language in terms of entries in domain dictionary Factors of Variation Domain Model Captures variability within the domain Defines terms required to express shared properties Feature Model Gives an overview of the domain model with special emphasis on variability

Page 9 Design Model Two Meta-Models covering data pool and parameter database concepts Control Framework Meta Model UML2 Model UML2 Model covering Activity and Mode Management concepts UML2 Model UML2 Model covering all parts of the DH Framework CORDET Framework Design Model UML2 Models are merged in one single

Page 10 Embedding Rules Additional Component Functional Component CASE 1: Functional component can be embedded “as is” in RCM container Additional component that interfaces the functional component with the RCM container RCM Container Functional Component Functional Component CASE 2: Functional component must be combined with an additional component Functional Component RCM Container

March ASSERT WP4.2 – Framework Development Experiment Telecommand Concept TcStream TcLoader TcManager Raw TC data are read by the TcLoader from the TcStream The TcLoader de-serializes the raw TC data and constructs the TC components PUS Application Process The TC components are loaded into the TcManager component(s) The TcManager is responsible for executing the TC components TcFactory The TcLoader takes unconfigured TC components from the TcFactory The TcManager returns completed TC components to the TcFactory

March ASSERT WP4.2 – Framework Development Experiment Cyclical Telemetry Concept TmStream AppComp TmManager PUS Application Process TM packets are loaded and unloaded into the TmManager by application components The TmManager is responsible for managing the list of pending TM packets and periodically asking them to update themselves and serialize themselves to the TmStream TmFactory The TmFactory returns unconfigured TM packet components Each TmManager is associated to the TmStream Terminated TM packets are returned to the TmFactory TmRegistry filters TM packets Application component wish to create and send a TM packet