28 August 2003 Object Orientation modelling with UML and HRT-UML Case study: AOCS Framework Martin JEAN-BAPTISTE End of studies training period Software

28 August 2003

Object Orientation modelling with UML and HRT-UML

Case study: AOCS Framework

Martin JEAN-BAPTISTE

End of studies training period

Software Engineering and Standardisation Section

28 August 2003 AOCS Object Oriented modelling Martin JEAN-BAPTISTE, TOS-EME22

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


Introduction and motivations

• 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


Contents

• Introduction and motivation






• Conclusion


Design Principles of the AOCS Framework

• Truly object-oriented methodologyTruly 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:Use of Design Patterns: optimised reusable architectural solutions

• Multiple inheritanceMultiple inheritance: adapted for mission-critical applications

- only single inheritance of implementation

- multiple inheritance of interface

• A component-based frameworkA component-based framework: to allow inter-operability across language, compiler, process, and processor barriers.

• Behaviour adaptation in the framework instantiation process:Behaviour adaptation in the framework instantiation process:- Inheritance for static behaviour adaptation

- Object composition for dynamic behaviour adaptation



Typical AOCS software functionalitiesTypical AOCS software functionalities

• Attitude control function

• Orbit control function

• Telecommand Processing

• Telemetry Processing

• Failure Detection and Isolation

• Failure Recovery

• Reconfigurations

• Manoeuvre Execution

AOCSComputer

Ground Station

Measurements Commands

Failure Detectionand Recovery

ReconfigurationManagement

Control LoopManagement

Operational ModeManagement



The manager Meta-patternThe manager Meta-pattern

Real-Time Operating System model 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)

Applying this model to most of the functionalities of the

AOCS Framework


Contents







• Conclusion


UML model of the Java AOCS Framework

• Rationale for porting the AOCS Framework to JavaRationale 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 processUML 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


Resettable

ConfigurationState

Telecommand

UnitCommandReconfigurationListener

ConsistencyCheckable

AttitudeDataPool

DataSource

ControlChannelBlock

ControlChannelSuperBlock

UnitFunctional

ResetCommand TestAnalogActuatorCommand TestAnalogSensorCommand

DataSink

UnitBasicUnitReconfigurer

ActiveObject

DeltaChange NoChange OutOfRangeChange SimpleChange

DummyAocsClock

AocsClock

RootObject

AttitudeSlew DummyManoeuvreModeChangeAction

NullModeChangeAction TestModeChangeAction

Monitorable

ChangeObject

AocsData

AocsDataPool

MonitoringCheckEventRepositoryReconfigurerHelper AbstractControlChannel

RecoveryAction

ModeChange NullRecoveryAction

AocsObject

ObjectReset

ReconfigurationSystemReset LocalRecoveryActions

SystemResetOnConfigurationError

SystemResetOnTooManyFailures

TestTelemetryStream

TelemetryStream

UnitTriggerStrategy

DefaultUnitTriggerStrategy

AdderBlockBiasScalingCompensator

D_Block

DifferenceBlock

I_Block LimitBlock P_BlockPassThruBlock

Control ler

SplitterBlock

TorqueToThrusterPrototype TwoByTwoMatrixBlock

ManoeuvreManager

ManoeuvreTelecommand ModeChangeTelecommand

ReconfigureTelecommand

SystemManager

ResetTelecommand

TelemetryFormatTelecommand

TelecommandManager

TransactionTelecommand

ModeChangeTransactionTelecommand

Reconfigurable

ReconfigureTransactionTelecommand

Telemeterable

TelemetryFormatTransactionTelecommand

ObjectList

The subclasses of classes EventRepository and ObjectList are not represented in this diagram.

AocsMissionModeManager CyclingModeManager

ModeManager

FollowerModeManager

CyclingControllerModeManager CyclingTelemetryModeManager

FollowerFailureDetectionModeManager

RecoveryStrategy

FollowerFailureRecoveryModeManager FollowerControllerModeManager FollowerUnitStrategyModeManager

ModeListener

Control lerModeManager

Control lerManager

FailureDetectionModeManager

FailureDetectionManager

FailureRecoveryModeManager

FailureRecoveryManager

UnitModeManager

UnitManager

TelemetryModeManager

TelemetryManager

TestAnalogActuator

TestAnalogSensor

UnitHousekeeping

EventObject

Configurable

Resettable

Telemeterable

ChangeEvent

ManoeuvreEventModeEvent

ReconfigurationEvent

RecoveryEvent

SystemEvent

TelecommandEvent

FailureEvent

ConfigurationEvent

AocsEvent

Manoeuvre

Configurable

Mode Change Actions

Telecommands

Unit commands

Object Monitoring

Units

Sequential Data Processing

Manoeuvres

Recovery Actions

Recovery Strategies Mode Managers

Functionalities Managers

Object Lists

AOCS Events

AOCS Data


Unit trigger

strategy


Basic classesBasic classes

Ability to fire failure and configuration events to their event listeners

Management of event listeners lists

Inherited from interface telemetrable

Inherited from interface configurable

Inherited from interface resetable

Return current time an cycle provided by the Aocs clock plug-in object

Plug-in of the system manager

Retrieve event listeners lists

Internal services (protected methods )

External services (public interfaces)

Plug-in of a destruction recovery action

Constructor: register with system manager by a call to the method internalAddAocsObject() of class SystemManagerSystemManager. Set telemetry image length, and reset state by a call to methods localReset() and localResetConfiguration().

Unload all static plug-in objects and all registered listeners



Component communicationComponent communication



Component communicationComponent communication

Example of failure event creation

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.



Controller managementController management

Instantiation of the controller design

pattern



Failure detection managementFailure detection management

Instantiation of the failure detection design pattern



Failure recovery managementFailure recovery management

Instantiation of the failure recovery design

pattern


System managementSystem management

Instantiation of the system management design pattern for the

system reset function



System managementSystem management

Instantiation of the system management design pattern for the

system configuration check function



Telecommand managementTelecommand management


Instantiation of the command

management design pattern


Telemetry managementTelemetry management


Instantiation of the telemetry

management design pattern


Contents







• Conclusion


Automated Framework Instantiation (AFI) projectAutomated Framework Instantiation (AFI) project

Instantiation of the Java AOCS Framework

ApplicationModel / Spec

ComponentComposition Env.

FormalComp. Description

FrameworkComponents

FormalConfiguration Desc.

ApplicationCode

Encoding Process

Code GenerationProcess

Item covered by theAOCS f/w project

Items coveredby the AFI project

Standard BeanComposition Tool

XML-BasedXSLT

Program


Automated Framework Instantiation projectAutomated 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 interestonly the characteristics of the components that are relevant to the

instantiation process need to be modelled

• To each fw component a visual proxy componentvisual proxy component is 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 Users perform the instantiation process in the On-Board Software (OBS) Bean Builder upon the visual proxy beans and their (OBS) Bean Builder upon the visual proxy beans and their

instantiation actions are later transposed to the fw components to instantiation actions are later transposed to the fw components to create the final applicationcreate the final application


Automated Framework Instantiation: Automated Framework Instantiation: OBS Bean Builder composition environmentOBS Bean Builder composition environment



Contents







• Conclusion


Introduction to the HRT-UML toolset

HOOD and HRT-HOODHOOD and HRT-HOOD

HOOD

• HOOD objects have provided provided andand required interfaces required interfaces and are internally structured as a set of co-operating child objects

• HOOD objects may be activeactive or passivepassive and have a structural textual description, called Object Description SkeletonObject Description Skeleton (ODS)(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 cycliccyclic and sporadicsporadic objects

• Introduction of protectedprotected object to permit controlled sharing of resources

• Improvement of the HOOD ODS to permit the expression of the real-time attributes 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.



Mapping HRT-HOOD to UMLMapping HRT-HOOD to UML

• Inversion of the Object-Oriented development paradigm in HRT-UML system

Normal OO development

HRT-UML development Singleton HRT-HOOD

Class model main constructive model

background concept

Isomorphic

Object model analysis aid main constructive model

• The underlying classunderlying class model in HRT-UML enables multiple static instantiation at design time by cloning the structure defined by a prototype instanceprototype instance

• Any HRT-UML object carries a descriptordescriptor, 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 objectplaceholder object is introduced to specify the required interface to be satisfied when a new instance is created



HRT-UML toolsetHRT-UML toolset


Contents







• Conclusion


Applying HRT-UML to the AOCS Framework

Recasting AOCS objects into the objects types allowed by HRT-UMLRecasting AOCS objects into the objects types allowed by HRT-UML(see picture on next slide)(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 interface ActiveObject in the Java release of the framework should be mapped to HActive including an HCyclicHActive including an HCyclic child object in the HRT-UML model

– Except the TelecommandLoader that should be mapped to HActive HActive including an HSporadicincluding an HSporadic child object in the HRT-UML model

Passive objects (objects not implementing interface ActiveObjects) should be mapped to HProtectedHProtected objects because the operations they expose can be called by any component from any thread during concurrent execution.



Main object model diagramMain object model diagram



• 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

Mapping the methods from a Java class to the HRT-UML operationsMapping the methods from a Java class to the HRT-UML operations

(see example of the failure detection manager further)(see example of the failure detection manager further)



• 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.

Internal topology of an active managerInternal topology of an active manager

(see example of the failure detection manager on next slide)(see example of the failure detection manager on next slide)


Separate diagram of the failure Separate diagram of the failure detection managerdetection manager



Details about the concept of placeholder objectDetails about the concept of placeholder object

When new instances are created a

placeholder item shows explicitly the relationships to be

satisfied

Use relations in the main object model

Used objects appear in the active manager environment of the separate diagram


Conclusion

• The AOCS Framework Project adopts a truly object-oriented methodology 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-UMLImprovements 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 A very promising object-oriented tool object-oriented tool

combining component combining component reusability and a reusability and a

computational model computational model adapted to the design adapted to the design

of hard real-time of hard real-time systemssystems

Documents

28 August 2003 Object Orientation modelling with UML and HRT-UML Case study: AOCS Framework Martin JEAN-BAPTISTE End of studies training period Software