Object Orientation modelling with UML and HRT-UML Case study: AOCS Framework

Object Orientation modelling with UML and HRT-UMLCase study: AOCS Framework Martin JEAN-BAPTISTE End of studies training period Software Engineering and Standardisation Section

Contents • Introduction and motivations • Design principles of the AOCS Framework • UML model of the java version of the AOCS Framework • Instantiation of the java AOCS Framework • Introduction to the HRT-UML toolset • Issue in applying HRT-UML to the AOCS Framework • Conclusion AOCS Object Oriented modelling

Satellite systems become increasingly software intensive A need for cost and planning reduction in the lifecycle of software development Object Orientation: a way to increase reusability but a customisation is necessary for space applications Mission criticality of space on-board software has led ESA and the European aerospace community to define their own software design methodology: HRT-HOOD HRT-UML: a mapping from HRT-HOOD onto UML by preserving the significant real-time process of the former and importing Object Oriented flexible features of the latter Introduction and motivations AOCS Object Oriented modelling

Contents • Introduction and motivation • Design principles of the AOCS Framework • UML model of the java version of the AOCS Framework • Instantiation of the java AOCS Framework • Introduction to the HRT-UML toolset • Issue in applying HRT-UML to the AOCS Framework • Conclusion AOCS Object Oriented modelling

Truly object-oriented methodology: the emphasis is put on abstract interfaces. Interaction between components is always performed through the interfaces, never through the concrete classes implementing them. Use of Design Patterns: optimised reusable architectural solutions Multiple inheritance: adapted for mission-critical applications only single inheritance of implementation multiple inheritance of interface A component-based framework: to allow inter-operability across language, compiler, process, and processor barriers. Behaviour adaptation in the framework instantiation process: Inheritance for static behaviour adaptation Object composition for dynamic behaviour adaptation Design Principles of the AOCS Framework AOCS Object Oriented modelling

Typical AOCS software functionalities Attitude control function Orbit control function Telecommand Processing Telemetry Processing Failure Detection and Isolation Failure Recovery Reconfigurations Manoeuvre Execution Design Principles of the AOCS Framework AOCS Object Oriented modelling

Design Principles of the AOCS Framework Real-Time Operating System model • An abstract interface capturing the behavioral signature of the functionality • An functionality manager component (a core component)maintaining a list of objects seen as instances of the functionality interface • Default implementations of the functionality interface (default components) The manager Meta-pattern Applying this model to most of the functionalities of the AOCS Framework AOCS Object Oriented modelling

Rationale for porting the AOCS Framework to Java It has a built-in support for multitasking It has an associated component model: the Java Beans To evaluate Java for space application: Java is currently unsuitable for space applications due to the overhead of interpretation Its wide user base leads to low costs UML Model design process Names of classes, methods and operations obtained by reverse engineering Class diagrams: to show inheritance and dependencies between classes as well as interfaces implementation Sequence diagrams: to model relevant functions used during initialisation and operational phases State diagrams: manoeuvre state machine and mode transitions UML model of the Java AOCS Framework AOCS Object Oriented modelling

UML model of the Java AOCS Framework Telecommands Unit commands AOCS Events Functionalities Managers Object Lists AOCS Data Manoeuvres Unit trigger strategy Mode Change Actions Recovery Actions Units Recovery Strategies Mode Managers Sequential Data Processing Object Monitoring AOCS Object Oriented modelling

Basic classes Internal services (protected methods ) Ability to fire failure and configuration events to their event listeners Constructor: register with system manager by a call to the method internalAddAocsObject() of class SystemManager. Set telemetry image length, and reset state by a call to methods localReset() and localResetConfiguration(). Return current time an cycle provided by the Aocs clock plug-in object Plug-in of the system manager Plug-in of a destruction recovery action Retrieve event listeners lists Unload all static plug-in objects and all registered listeners External services (public interfaces) Inherited from interface resetable Inherited from interface configurable Inherited from interface telemetrable Management of event listeners lists AOCS Object Oriented modelling

UML model of the Java AOCS Framework Component communication AOCS Object Oriented modelling

UML model of the Java AOCS Framework Component communication Event mechanism is compatible with the Java Beans event model to ensure that the framework events can be manipulated by standard beanbox environment. However Java applications typically create a new event dynamically before firing it, this is not allowed in the framework. The adopted model is as follows. Example of failure event creation AOCS Object Oriented modelling

UML model of the Java AOCS Framework Controller management Instantiation of the controller design pattern AOCS Object Oriented modelling

UML model of the Java AOCS Framework Failure detection management Instantiation of the failure detection design pattern AOCS Object Oriented modelling

UML model of the Java AOCS Framework Failure recovery management Instantiation of the failure recovery design pattern AOCS Object Oriented modelling

UML model of the Java AOCS Framework System management Instantiation of the system management design pattern for the system reset function AOCS Object Oriented modelling

UML model of the Java AOCS Framework System management Instantiation of the system management design pattern for the system configuration check function AOCS Object Oriented modelling

UML model of the Java AOCS Framework Telecommand management Instantiation of the command management design pattern AOCS Object Oriented modelling

UML model of the Java AOCS Framework Telemetry management Instantiation of the telemetry management design pattern AOCS Object Oriented modelling

Instantiation of the Java AOCS Framework Automated Framework Instantiation (AFI) project Item covered by the AOCS f/w project Application Model / Spec Standard Bean Composition Tool Items covered by the AFI project Component Composition Env. XML-Based XSLT Program Formal Comp. Description Formal Configuration Desc. Code Generation Process Encoding Process Framework Components Application Code AOCS Object Oriented modelling

Instantiation of the Java AOCS Framework Automated Framework Instantiation project • Application is component-based, a component is characterized only by its external interface • only the externally visible characteristics of the components need to be modelled • Only application instantiation process is of interest • only the characteristics of the components that are relevant to the instantiation process need to be modelled • To each fw component a visual proxy componentis associated that is a visualizable Java Beans. They can be manipulated in a bean composition environment that models the instantiation-relevant part of the fw component. Users perform the instantiation process in the On-Board Software (OBS) Bean Builder upon the visual proxy beans and their instantiation actions are later transposed to the fw components to create the final application AOCS Object Oriented modelling

Instantiation of the Java AOCS Framework Automated Framework Instantiation: OBS Bean Builder composition environment AOCS Object Oriented modelling

Introduction to the HRT-UML toolset HOOD and HRT-HOOD • HOOD • HOOD objects have provided and required interfaces and are internally structured as a set of co-operating child objects • HOOD objects may be active or passive and have a structural textual description, called Object Description Skeleton(ODS) which defines the meta-model of the method • HRT-HOOD (based on HOOD 3.1) • HRT-HOOD broke the concept of active object into cyclic and sporadic objects • Introduction of protected object to permit controlled sharing of resources • Improvement of the HOOD ODS to permit the expression of the real-time attributes (e.g. period, deadline, priority, worst-case execution time ) • HRT-HOOD is now an industrially-applied method because it provides a design freedom for structural conformance to rigorously-defined computational model (like Ada Ravenscar profile) from analysis throughout to coding. AOCS Object Oriented modelling

Introduction to the HRT-UML toolset Mapping HRT-HOOD to UML • Inversion of the Object-Oriented development paradigm in HRT-UML system • The underlying class model in HRT-UML enables multiple static instantiation at design time by cloning the structure defined by a prototype instance • Any HRT-UML object carries a descriptor, a pair comprised of: • Underlying class: describes abstract properties of objects of that class (e.g. HRT type, provided operation type, required attributes ) • Prototype instance: describes the internal topology of the object • The concept of placeholder object is introduced to specify the required interface to be satisfied when a new instance is created AOCS Object Oriented modelling

Introduction to the HRT-UML toolset HRT-UML toolset AOCS Object Oriented modelling

Recasting AOCS objects into the objects types allowed by HRT-UML (see picture on next slide) In an typical instantiation active components are scheduled in accordance with a cyclical policy, except for the TelecommandLoader irregularly awakened by the arrival of a new telecommand, thus: Objects implementing interfaceActiveObjectin the Java release of the framework should be mapped to HActive including an HCyclic child object in the HRT-UML model Except the TelecommandLoader that should be mapped to HActive including an HSporadic child object in the HRT-UML model Passive objects (objects not implementing interface ActiveObjects) should be mapped to HProtected objects because the operations they expose can be called by any component from any thread during concurrent execution. Applying HRT-UML to the AOCS Framework AOCS Object Oriented modelling

Applying HRT-UML to the AOCS Framework Main object model diagram AOCS Object Oriented modelling

Applying HRT-UML to the AOCS Framework Mapping the methods from a Java class to the HRT-UML operations (see example of the failure detection manager further) • Public methods of the java class of an active manager are declared in the provided interface of the Active object in HRT-UML • Protected and private methods are only accessible by child objects inside the parent Active object • Methods marked “synchronised” (methods used during operational phase in multi-threading) in the java class are stereotyped HSER (Highly Synchronous Execution Request) in the active object and delegated to a PSER (Protected Synchronous Execution Request) operation in an internal protected object • Methods not marked “synchronised” (methods used during initialisation phase) are stereotyped ASER (ASynchronous Execution Request) in the active object and delegated to PAER (Protected Asynchronous Execution Request) operation in an internal protected object AOCS Object Oriented modelling

Applying HRT-UML to the AOCS Framework Internal topology of an active manager (see example of the failure detection manager on next slide) • As any active manager, the failure detection manager owns a protected child object (named NameOfTheManagerProt), a kind of constructor for the manager where its specific operations are delegated • Services common to all active managers as configuration error reporting, failure reporting, telemetry, reset and configuration are represented by instances of the corresponding classes  Due to the multiple static instantiation • The cyclic behaviour of the manager is represented by an HCyclic object which thread action performs the task of the method runOneCycle() of the java program • Some of the objects used by the cyclic object are child objects of the manager because it is composed by them (in the sense of the composition relationship defined by UML), it means that the manager’s class owns one attribute of the corresponding type for each of them. The others are defined in the object’s environment and could eventually be included in another object. AOCS Object Oriented modelling

Separate diagram of the failure detection manager AOCS Object Oriented modelling

Applying HRT-UML to the AOCS Framework Details about the concept of placeholder object Use relations in the main object model Used objects appear in the active manager environment of the separate diagram When new instances are created a placeholder item shows explicitly the relationships to be satisfied AOCS Object Oriented modelling

Conclusion • The AOCS Framework Project adopts a truly object-orientedmethodology which puts the emphasis not on objects but on abstract interfaces. • The term object-oriented design as used in the space sector (e.g. HRT-HOOD) often refers to systems that are more properly called object-based. • Currently HRT-UML design methodology is more object-based rather than object-oriented. Thus, delegation of responsibility is not possible and reusability less easy. But system complexity is always handled through hierarchical object decomposition. • Improvements foreseen for the future release of HRT-UML • Accepting UML interfaces • Accepting inheritance in a controlled way • Fiting the Ravenscar Profile • Improving hierarchical modelling through packages and subsystems A very promising object-oriented tool combining component reusability and a computational model adapted to the design of hard real-time systems AOCS Object Oriented modelling

Object Orientation modelling with UML and HRT-UML Case study: AOCS Framework