OSRAP
Abstract
31.01.2015
On-board Software Reference
Architecture for Payloads
Presenters
Victor Bos, phone: +358 400897907, email: [email protected]
Adam Trcka, phone: +420 736650822, email: [email protected]
Introduction
This abstract summarizes the On-board Reference Architecture for Payloads activity carried out by Space
Systems Finland (SSF) and Evolving Systems Consulting (ESC) under ESA contract. At the time of writing, the
activity is ongoing. This abstract discusses study objectives, related activities, study approach, achieved and
anticipated results, and directions for future work.
Context and objectives
Current practices of software development of satellite payloads, although conforming to the applicable ECSS
standards like ECSS-E-ST-E40C and ECSS-ST-Q80C, are rather isolated of each other. This has led to a situation
where not only payload-specific software but also more generic functionality is developed from scratch.
Clearly, current practices can be made more efficient if, throughout the whole software life cycle, generic
functionality and software architecture and engineering guidelines can be identified and reused between
payloads.
Similar observations have been made for platform level software, which have led to various activities to
improve platform software development. One of the main results of these activities is the On-board Software
Reference Architecture (OSRA) for platform software (see [R3], [R4], [R5], [R6]). Provided the OSRA is adopted,
it will improve reuse of software elements (like requirements, design, test specifications, source code, and test
procedures) in different development activities.
By building upon existing results related to OSRA , the current activity aims at defining an On-board Software
Reference Architecture for Payloads (OSRA-P).
Related activities
1.
2.
3.
COrDeT2/3: a model- based and component-based software development approach focusing a
layered architecture composed of components and interfaces (see [R3], [R5], [R6]). Components are
defined for each particular function and layers are formed from component groups based on
application specificity and hardware dependency.
SAVOIR-FAIRE: aims at creating a software reference architecture, based on open interface standards
(see [R1], [R2]). Similar to COrDeT, it envisions having building blocks but expands on the principles by
including avionics and functional chains.
IMA-SP: coming from Time and Space Partitioning (TSP) principles and the Integrated Modular
Avionics (IMA) systems from the aviation domain, IMA-SP attempts to recreate IMA concepts for the
Space domain (see [R7], [R8]). This focuses on the HW, avionics and resource partitioning between
software elements of a system, acknowledging the layered software architecture approach but
focusing on integration of mixed criticality level applications. The study highlights commonalities,
differences and applicability of these activities with regards to OSRA-P.
1
OSRAP
4.
Abstract
31.01.2015
LVCUGEN, xLuna, and PISA: previously software platforms with partly overlapping goals to harmonize
and improve payload software development (see [R11], [R9], [R10]).
Towards OSRA-P
Payload catalogue
We started by collecting information about actual payload instruments and recording this in the Payload
Catalogue. It provides information about function, stake-holders, design drivers, software architecture, and
development processes.
The payloads in the catalogue were chosen from recent (or even current) payload development activities.
Another selection criterion was the availability of experts to provide detailed information. We interviewed
several payload experts currently active in the European space industry. Based on their inputs and on publicly
available documentation, we documented 10 different payload instruments.
In order support comparison activities, the Payload Catalogue also includes a Capability Matrix. It is a two
dimensional table with one row for each payload instrument. Each column represents a capability: a payload
characteristic like processor module, memory storage needs, computational power, FDIR, RTOS, downlink
bandwidth, and instrument power consumption. From the values in this matrix, industry wide patterns can be
seen, such as the average computational power of a payload all the way to its expected downlink bandwidth.
Domain analysis
Composing the Payload Catalogue and its Capability Matrix was the first step to explore the domain of payload
software. The next step was to analyze the obtained data and to identify commonalities and differences that
are relevant to the software development and architecture. This bottom-up analysis resulted in three concrete
results:
Domain dictionary
The domain dictionary defines terminology used by the payload (software) community. Terms can have
different interpretations depending on background and role of people within this community. The domain
dictionary tries to resolve such issues at least for the scope of the OSRA-P study.
Feature diagrams
A feature diagram is a hierarchical representation of payload characteristics, or, features. We derived the
features from the capability matrix: each specific capability is a feature and related features are grouped into
higher-level abstract features. The feature diagram indicates if sub-features are mandatory or optional and if
they are mutually exclusive. The resulting feature diagram (partly included in Figure 1) is an effective tool to
determine similarities and differences between specific payloads. It also hints at design decisions taken by
payload (software) developers while implementing specific payloads. For instance, by instantiating the feature
diagram for a specific payload instrument, the decisions taken when alternative solutions were present
become clear.
Functional decomposition
Our functional decomposition describes the main functions found in payload software. The functions are part
of a hierarchy which shows how more complex functions are built up from simpler functions. The resulting
functional decomposition is a tool to support requirements specification. Therefore, once the OSRA-P has been
defined, it can be validated by tracing the architecture to the functional decomposition. Figure 2 shows the
functional decomposition as a mindmap (with some nodes collapsed).
2
OSRAP
Figure 1: OSRA-P Feature Diagram
Abstract
31.01.2015
Figure 2: OSRA-P functional decomposition
Architecture definition
Architecture descriptions in the Payload Catalogue include both static and dynamic software architecture.
Consequently, the OSRA-P shall include both static and dynamic aspects of software architecture. Moreover, it
aims at specifying such aspects in terms of generic components (as done in OSRA) that can be reused to
develop architectures of application specific software.
Payload software (like most embedded software) can be presented in a layered architecture with three layers:
hardware dependent software, generic software, and application specific software. The hardware dependent
software encapsulates real-time operating systems (RTOS); drivers for connected equipment and devices; and
board support package software. On top of this, generic functionality including communication protocols;
data-, memory-, and time-management; and monitoring-and-control services are implemented. The top-level
implements payload specific functionality like: payload-mission operations, thermal control, and FDIR. Figure 3
illustrates the three-layer software architecture.
The diagram of Figure 3 is an initial version of OSRA-P. To complete the OSRA-P definition, interfaces of and
interactions among the identified blocks in each layer are being described. The focus of these descriptions is
on the Generic Software layer.
The OSRA reference architecture from COrDeT-2/3 also identifies a set of generic functionality, called the
Execution Platform. The specification of the Execution Platform is an important source of information for the
definition OSRA-P. Whenever generic functionality present in OSRA is needed or useful for payload software,
the approach is to reuse the OSRA specification in OSRA-P. Consequently, the OSRA-P can be seen as a tailoring
of OSRA.
In addition to the Execution Platform, OSRA also defines a component model with which application software
can be developed. We expect that reuse of the OSRA component model in payload software development has
potential. However, as the payload software development community is more diverse than the platform
software development community, it might be unrealistic to expect harmonization towards a single
component model.
3
OSRAP
Abstract
31.01.2015
Application Specific Software
Payload
operations
Thermal
control
FDIR
Generic Software
Monitoring
Reporting
Memory mgt
TM/TC
Time mgt
Data mgt
Hardware Dependent Software
Equipment
drivers
RTOS
Board
Support
Package
Figure 3: Three-layer software architecture
Evaluation of OSRA-P
This section describes how we evaluate OSRA-P.
Relation to standards and recommendations
As already mentioned, payload software development usually follows requirements of the ECSS standards (like
“E40C” [R12], “Q80C” [R13], and the PUS standard [R14]). In addition, CCSDS recommendations are usually
applicable (e.g., [R15], [R16], [R17], [R18], and [R19]). Therefore, the relation between OSRA-P and these ECSS
and CCSDS standards will be investigated. We will investigate how OSRA-P relates to these standards and
recommendations.
Case studies
In order to validate the OSRA-P, case studies will be performed: (parts of) actual payload software will be redeveloped using the OSRA-P as a starting point. The case studies shall demonstrate OSRA-P. As such, the goal
is to highlight OSRA-P’s potential to improve payload software development. At the same time, the case
studies will likely uncover shortcomings and such feedback will be used to improve OSRA-P.
Future work
Once an initial OSRA-P has been established, follow-up activities could be started. Such activities can focus on
disseminating OSRA-P results in the payload software development community by, for instance, providing
OSRA-P training or performing case studies. Another area of future work concerns development of tool
support for OSRA-P. Prototype tool support, as developed for OSRA, is needed to perform larger case studies.
In addition, there will be a need for an implementation and demonstrator of OSRA-P. The implementation shall
provide a substantial part of the Generic Software and it shall run on a representative (possibly simulated)
platform. The demonstrator shall implement a typical payload application. Together, the OSRA-P
implementation and demonstrator can be used in workshops and trainings about OSRA-P.
References
[R1] SAVOIR Functional Reference Architecture, TEC-SW/11-477/JLT, Issue 3, 11/05/2012.
[R2] SAVOIR Avionics Systems Reference Architecture Platform Payload Interface Specification, Draft 3,
17/02/2012.
4
OSRAP
Abstract
31.01.2015
[R3] COrDeT 2 Deliverable R6 – On-Board Software Reference Architecture Specification, GMVAD 20566/12
V8/12, Issue 2.1, December 2012.
[R4] Software Reference Architecture - Presentation of the OSRA Specification, Session led by Mr. Andreas
Jung (ESA/ESTEC - Software Systems Division), ADCSS 2014.
[R5] Onboard Software Reference Architecture: Rationale, Peter Mendham/Bright Ascension, Elena
Alaña/GMV, Santiago Urueña/GMV, D02-OSRA-RAT, V1.0, 22/12/14.
[R6] Onboard Software Reference Architecture: Specification, Peter Mendham/Bright Ascension, Elena
Alaña/GMV, Santiago Urueña/GMV, D02-OSRA-SPEC, V1.0, 22/12/14.
[R7] IMA-SP D10 – TSP Services Specification, Issue 2.1, Date 13/03/2012.
[R8] SISTORA (Study on IMA Space – TSP in the OBSW Reference Architecture Context) Final Report,
SSL/08701/RP/0001, Issue 3.2, Date 24/10/2012.
[R9] XLUNAOSQUAL (xLuna OS Qualification) Final Report, CSWXLUNAOSQUAL-2012-RPT-04401, Issue 02,
March 2013.
[R10] PISA (Principal Investigator Software Architecture) Final Report, PISA-RPT-001-SYD, Issue 1,
6/11/2006.
[R11] Galizzi J. et al., “LVCUGEN (TSP-based solution) and first porting feedback”, ERTS 2012.
[R12] ECSS-E-ST-40C March 2009, Space Engineering – Software.
[R13] ECSS-Q-ST-80C March 2009, Space Product Assurance – Software Product Assurance.
[R14] ECSS-E-70-41A January 2003, Space Engineering – Ground systems and operations – Telemetry and
telecommand packet utilization.
[R15] CCSDS 850.0-G-1 Spacecraft Onboard Interface Services (Green Book), Issue 1, June 2007.
[R16] CCSDS 851.0-M-1 Spacecraft Onboard Interface Services – Subnetwork Packet Service (Magenta
Book), Issue 1, December 2009.
[R17] CCSDS 852.0-M-1 Spacecraft Onboard Interface Services – Subnetwork Memory Access Service
(Magenta Book), Issue 1, December 2009.
[R18] CCSDS 872.0-M-1 Spacecraft Onboard Interface Services – Time Access Service (Magenta Book), Issue
1, January 2011.
[R19] CCSDS 873.0-M-1 Spacecraft Onboard Interface Services – File and Packet Store Service (Magenta
Book), Issue 1, September 2012.
5