On-board Software Reference Architecture for Payloads

Transcription

1 On-board Software Reference Architecture for Payloads Presenters Victor Bos, phone: , Adam Trcka, phone: , 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. 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. 2. 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. 3. 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

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

3 Figure 1: OSRA-P Feature Diagram 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

4 Application Specific Software Payload operations Thermal control FDIR Monitoring Generic Software Reporting Memory mgt TM/TC Time mgt Data mgt Hardware Dependent Software Equipment drivers RTOS Board Support Package Evaluation of OSRA-P This section describes how we evaluate OSRA-P. Figure 3: Three-layer software architecture 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/

5 [R3] COrDeT 2 Deliverable R6 On-Board Software Reference Architecture Specification, GMVAD 20566/12 V8/12, Issue 2.1, December [R4] Software Reference Architecture - Presentation of the OSRA Specification, Session led by Mr. Andreas Jung (ESA/ESTEC - Software Systems Division), ADCSS [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 [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 [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 G-1 Spacecraft Onboard Interface Services (Green Book), Issue 1, June [R16] CCSDS M-1 Spacecraft Onboard Interface Services Subnetwork Packet Service (Magenta Book), Issue 1, December [R17] CCSDS M-1 Spacecraft Onboard Interface Services Subnetwork Memory Access Service (Magenta Book), Issue 1, December [R18] CCSDS M-1 Spacecraft Onboard Interface Services Time Access Service (Magenta Book), Issue 1, January [R19] CCSDS M-1 Spacecraft Onboard Interface Services File and Packet Store Service (Magenta Book), Issue 1, September