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