Software Product Lines within Airbus Defence & Space

Transcription

1 Software Product Lines within Airbus Defence & Space Space Systems Business Line BEUGNET Laurent Common Software Governance within Airbus D&S Common Engineering

2 Airbus Defence and Space Organisation overview 2

3 Space Systems Business Line No. 1 in European satellites No. 1 in commercial launchers With its own cutting-edge design, production and test capabilities, Space Systems possesses expertise in all the key skills and technologies required for designing, developing and operating major space systems: from launchers to the in-orbit delivery of satellites, planetary and deep-space missions and International Space Station activities. Expertise in satellites, launchers, deterrence, human space flight Telecom Satellites Earth Observation Navigation & Scientific (= ENS ) Satellites Launchers (Ariane) Orbital Systems Defence 3

4 Software Product Lines within Airbus Defence & Space - Space Systems Telecom Satellites 4

5 Telecom spacecraft simplified layout Deployable Antennas Top floor antennas Repeater equipment Communications Module Payload walls Propulsion Tanks Service Module Solar array Batteries Avionics Liquid Apogee Engine 5

6 Telecom spacecraft: from mission to Avionics Product Telecom spacecrafts missions Specific payload for each mission Generic mission: geostationary, earth-pointing Eurostar 3000 platform: 34 spacecrafts in-orbit, 12 in-development Segmentation of E3000 product to cover all missions range Product line is streamlined with a common avionics, a scalable power subsystem and variant limited to mechanical platform (structure and propulsion) 6

7 Telecom spacecraft: functional product design Single generic product covering all mission ranges Applicable for Flight Software, System database, Operation & Test procedures, Simulators Instantiation to the mission done through Product alternatives selection (e.g. propulsion, launcher, HW variants) among 80 within the functional product catalog Mission tunings & customisation (power, thermal, ADCS, payload ). System database is a key element in the missionisation process No SW development activities for spacecrafts within qualified product range Validation through Regression campaigns: to verify compliance of instantiated products with respect to CPU, memory and real-time requirements Validation of mission tunings and customisation Alternatives selection Mission tunings/custom Generic product Mission product Regression tests Product evolutions Versioning done at product level, in close synergy with system needs All evolutions implemented first at generic level Recurring missionisation requirements taken into account in early design phase Mission/System tests Delivery 7

8 Telecom spacecraft missionisation: technos & tools System database Central element for missionisation process & tools Repository of most spacecraft data: Telemetry & Telecommand, tunings, Failure Detection Isolation & Recovery (FDIR), calibrations, on-board procedure parameters Automated import and export tools Flight Software Automatic generation tools: Production Program For non-selected alternatives conditional compilation (SW code not generated in mission SW) software code inhibition (SW code generated but inhibited through data management) For Eurostar Neo (next generation Eurostar Platform): plan to have a single software code for all missions (common memory map, bus traffics, CPU budgets) with capability to inhibit undesired functions through mission parameters. Objective: decrease REC cost (no regression test campaign) Operational and test procedures/sequences Test languages and infrastructure allow definition of generic multi-option test procedures, allowing common procedure base for the whole fleet Automation of test execution at user level (validation, AIT) 8

9 Telecom spacecraft: flight software product overview wrt E3000 fleet 9

10 Software Product Lines within Airbus Defence & Space - Space Systems Earth Observation Navigation & Scientific Satellites 10

11 Product Lines within AstroBus Catalogue 11

12 AS250 Insure Consistency AS250 Product main purpose HW + SW +. Flight proven Avionics design: Power & Data Handling Systems, TM/TC Chain, P/L Data Management, Central Software, Database, AOCS, Operations, with associated documentation Avionics Space hardened qualified units (PFM/EQM) centrally procured through Long Term Agreements Units Inputs to satellite platform Mechanical, thermal, harness Solar Array, Propulsion Accommodation constraints Platform Validation strategy, Overall Test Matrix, Test plans & specifications, AIT procedures, Key Interface Data list AIT 12

13 Satellite Platform based on the AS250 avionics Primary Structure On-Board Computer Reaction Wheels Power Control Distribution Unit Magnetometer Star Tracker Electronics Compression & Memory Remote Interface Unit X-band Assembly Propulsion Battery 13

14 The AS250 Software Product Basic principles AS250 Software Product is composed of a set of software components a set of processes, tools and documents A software component implements a given functionality, it consists of a set of source code files a set of data to be set in the system database a set of documents chapters Software Requirements Specification chapter Telemetry/TeleCommand Interface Control Document chapter Software Validation Specification - Test Specification chapters Detailed Design Document (extracted from the code) a set of test procedures SOFTWARE COMPONENT Source code files Database data Document chapters Test procedures There are two types of components Generic : the component is used by several projects STR OCM Specific : the component is used by only one project Payload EQPT DCU 14

15 The AS250 Software Product Basic definitions The software generic components can be variant A variant enables to implement two or more variations of a given functionality Acquisition & Safe Hold Mode Bspin or Bdot ASH- BSPIN ASH- BDOT Control Momentum Gyroscope (CMG) or Reaction Wheels (RW) Different variants of a given functionality are thus exclusive The different variants of a component have identical interfaces The software generic components can have options The options allows implementing variation of functionalities within a given component Example : Star Tracker with 2 or 3 optical heads => option attached to STR component : 2OH or 3OH The selected options of a project are implemented within specific project configuration files An option is implemented in the code of the component by means of an If Then Else statement. This means that both branches are included in the code The code corresponding to the option of the project (e.g. If statement) is validated in the frame of the project The code corresponding to the non selected option of the project ( Else statement ) is not validated in the frame of the current project but is validated in the frame of another project CMG RW Project configuration file strohconf = 2OH isgyroless = TRUE 15

16 AS250 software catalogue Set of SW components The AS250 catalogue consists of the set of generic software components The Central Software projects are instantiated from this catalogue, e.g. Spot 6 & 7 Seosat Sentinel-5 Precursor Kazakhstan/DZZ-HR MN35-13 A set of specific software components (in addition to this catalogue) have been developed in the frame of above projects Generic Variant Specific Application Function Variant Component RTEMS RTEMS RTEMS_PRODUCT BOOT BOOT BOOTPROM DMS DMS AS250 DMS CDHS CDHS CDHS SIF OSIF (external) OSIF SIF SIF (internal) SIF MATHLIB MATH MATH LIBM LIBM AOCS Acquisition and Safe Hold Mode Acquisition and Safe Hold Mode B-SPIN ASHBS Acquisition and Safe Hold Mode B-DOT ASHBD Coarse Sun Sensor CSS Magnetometer MAG Magneto-Torquer MTQ Control Momentum Gyroscope CMG Inertial Actuators Reaction Wheels RW Inertial Measurement Unit IMU Star Tracker STR Global Positioning System function GPS Thruster management THRUST Navigation Function NAV Hybrid Stellar Estimation HSE Inertial attitude estimator IAE Dynamic stellar estimator DSE Attitude Control function SUP/GAP Guidance CTRL CTRL1 GUID GUID1 MAN/CAP Guidance with CMG MAN MAN/CAP Guidance with RW MANCAP2 MAN/CAP Guidance MAN/CAP Guidance with RW and with MANCAP1 MAN predictive computation Magnetic Off-Loading MOL On-board Orbit Propagator OOP Star tracker Measurement Fusion SMF Gyro-Stellar Estimator GSE BB SUPPORT SUPPORT Wheel Array Management WAM Normal Mode Management NM NM1 Orbit Control Mode Management OCM AOCS Modes AOCSMGR PF Remote Interface Unit RIU Power Conditioning and Distribution Unit S-band Transponder Bus Thermal Control PCDU TRSP TRSP1 TRSP3 THERMAL THERMAL1 THERMAL3 Battery Power Management POWER Solar Array Deployment SAD SAD1 S-Band TM Chain Management SBANDMGR1 S-Band Deciphering and Ciphering Unit RX SDCURX1 S-Band Deciphering and Ciphering Unit RX SDCURX2 S-Band Deciphering and Ciphering Unit TX SDCUTX1 PL XDA X-band Downlink Assembly Function XDA1 Instrument Video Unit IVU IVU1 Compression, Recording and Ciphering Function CORECI PDHU PDHU System Auxilliary Data Management DAS PLMGR Payload Management PLMGR1 PLMGR3 Complementary Scientific Payload CSP1 X-Band Chain Management XBANDMGR1 X-Band Deciphering and Ciphering Unit XDCU1 SYSTEM System Application SYSMGR 16

17 Instantiation of a new project from the AS250 Product (1/2) 1. Project initialisation Select generic and variant components within the catalogue My Project Develop specific components if needed (Payload or Platform) STR RW OCM IMU TRSP CORECI SAD ASH- BSPIN TRSP SPEC SAD SPEC Project configuration file strohconf = 2OH isgyroless = TRUE Configure the options chosen by the project in the project data files ASH- BDOT Data project files Create project data files filled with project data 17

18 Instantiation of a new project from the AS250 Product (2/2) 2. Software image construction The building of the software consists in compiling and linking together the components selected during the project initialization step and producing the executable software An incremental software life cycle is generally applied V1 : including all the generic components reused from AS250 Product (~ 80 %) V2 : final and complete software including the specific components 3. Software image validation Exhaustive validation campaign is run onto each project software image (tests, analysis and inspections) Validation objectives are demonstrated on each project without making any reference to previous projects Only exception: else branches of the options that are not validated on current project but on another project 4. Project documentation generation, using 3 different document types Documents based on an AS250 common part + a specific addendum (few) Documents based on software component chapters collection Documents which are project specific (reuse between projects possible) 18

19 Software component configuration management Example of component modification with maintenance branch Project specific configuration branch AS250 Product configuration branch COMPONENT AS250 Product V1 Project in maintenance V2 Modification to change the TM type of the GPS error message (improvement) Modification implemented in the AS250 Product only Modification dedicated to a bug fix (NC) Modification made TWICE!! Modification dedicated to a bug fix (NC) S1 V3 19

20 Conclusion and Lessons Learned 20

21 Conclusion & Lessons Learned Success factors for implementing and maintaining a SW Product Line The creation of a (SW) Product Line answers to a Business case (System to Software) and is facilitated by a Product oriented organisation Proper characterisation of the functional/system domain to cover (not too small, not too big) SW PL NREC developed by the SW experts of a central organisation with the (challenging) objective of hiding the SW implementation complexity and minimising the required SW knowledge and techniques to allow a proper instantiation SW PL instantiation performed by the engineering forces (architects) of the projects within the Business Lines (with the overarching objective to remain as much as possible within the functional domain of the Product) Unique System/Software flow allowing establishing a consistent set of components to maximise commonalities Minimise the number of variants, options, alternatives (warning concerning dependencies) => systematic challenging of the system needs Rigorous management of software component versioning and planning is key and requires an important knowledge (both technical and product design/implementation rules) Minimise the documentation production effort Minimise error prone activities through automated execution procedures (e.g. exchange of data with System, SW image generation) Keep it simple! 21

22 Conclusion & Lessons Learned Thank you for your attention! Questions? 22