COrDeT-2
Home Contact

gmv

An ESA Technological Research Program
  [home]-[activity-4]


Activity 4 - Consolidation of the software reference architecture

This activity is devoted to the compilation of the previous tasks outcomes in order to produce a consolidated specification of the reference architecture.

The proposed development process has been revisited considering ECSS E-ST-40C and Q-ST-80C applicable aspects, focusing on the applicability and reuse of the OBSW-RA for SW architecting and remarking possible incompatibilities and constraints.

OBSW-RA Specification


After the toolset development and the implementation of the case study, the OBSW-RA has been consolidated considering the feedback received.

The OBSW-RA is split into three layers: Component Layer, Interaction Layer and Execution Platform Layer. Those parts are intended to support the implementation of OBSW applications for satellites and space exploration system. Therefore, any functional feature (space domain-specific) needs to be reflected in the architecture. There are nevertheless some domain-neutral parts that are obviously addressed by the architecture and which are related to the implementation of real-time embedded aspects which are common to any embedded software domain.

SW Reference Architecture

The Component Layer contains the components. Components are pure functional units. Hence, they can only contain functional code that specifies the sequential behaviour of the component. Component interfaces host non-functional attributes (e.g., WCET). Nevertheless, all non-functional concerns (non-functional attributes of the user model) are excluded from the functional code attached to the interfaces.

A component is the unit of composition. The whole OBSW (i.e., the software system model) is built by creating assembly of components, deployed on an Execution Platform which takes care of their correct execution.

The Component Layer is implemented from the Component Model, the COrDeT-2 Space Component Model (SCM). The Component Model specifies the syntactic rules to create design entities and also establishes a design flow which comprises a series of steps that guide the designer in the process to create components, assemble them and ultimately produce the software system.

The binding mechanisms of components instances are implemented by the Interaction Layer by means of connectors which realize the communication means. The interaction among component instances is defined by binding the required and provided interfaces of different components instances. Component containers are bound to connectors allowing component instances to request remote services. Containers are responsible for the realization of the non-functional attributes declared at the operations of the interfaces of each component instance (e.g., scheduling). Thus, the Interaction Layer binds the Component Layer to the Execution Platform Layer.

The Execution Platform Layer provides services for I/O abstraction and Data Handling for the interaction with avionics devices such as sensors, actuators or payloads and for communications to/from ground or other space systems. The OSI-service model is used to describe the interfaces to the Execution Platform services. The OBSW-RA considers the following Execution Platform services: Monitoring and control services (i.e., Commanding, Reporting, Monitoring, Automation and Archiving), Avionic (SOIS) services (i.e., Time Access, Command and Data Acquisition and Message Transfer) and Domain-Neutral service (i.e., System Management and Tasking).

Finally, future lines of work have been identified. Here are listed some of them:

  • Usage of 1553 communication links: analysis of timing constraints.
  • Definition of the contents, standards and format applicable for the representation of the items included in the Spacecraft Database (SDB).
  • Hierarchy of components.
  • Components granularity.
  • SCM extensions: new model entities to represent dependability, safety, partitioning, time stamps for data monitored, etc.
  • Tool updates to include:
    • On-board Control Procedures (OBCPs). Refer to OBCP-BB project.
    • Operational modes and distributed systems.

Specification of the OBSW-RA and interfaces


The ECSS standards are to be tailored when re-using the OBSW-RA. Then, the process of deploying and implementing the OBSW-RA and the organizational roles of all stakeholders has been documented, covering:

  • The process and organizational roles for implementation of the RA and its use in projects by refining/tailoring the activities already performed in ESA projects following ECSS standards.
  • Link the process and organizational roles proposed to System and Software Engineering - Software life cycle processes in ISO 12207:2008; ISO/IEC 15288 and ISO/IEC 15504. Definition in a practical way without too theoretical or abstract schemes of the processes and a practical description of how a Reference Architecture impacts to the SW life cycle and ECSS.
  • Ensuring the cross-check of derived tooling requirements w.r.t. ECSS.

The figure below presents the activities performed when using the OBSW-RA approach. These activities and their outcomes have been analysed to check the link to ECSS requirements applicable in space projects, allowing an ECSS tailoring.

Component Layer

 

GMV