SVF User Requirements Specification

Transcription

1 LlSA Pathfinder S2.ASU RS 5030 I SVF User Requirements Specification CI CODE: UK EXPORT CONTROL RATING: Not Listed Rated By: T. Remion Prepared by: Barry McMahon & Thomas Remion Checked by: Dave.. I. Approved by:... Neil Dunbar/ G.Adams - Authorised : Date: zz2./7/oj...w..:...e: %.4\!.C Mike Backler 0 EADS Astrium Limited 2005 EADS Astrium Ltd owns the copyright of this document which is supplied in confidence and which shall not be used for any purpose other than that for which it is supplied and shall not in whole or in part be reproduced, copied, or communicated to any person without written permission from the owner. EADS Astrium Limited Gunnels Wood Road, Stevenage, Herlfordshire, SGI 2AS, England

2 Page 2 of 18 INTENTIONALLY BLANK

3 Page 3 of 18 CONTENTS 1. INTRODUCTION Scope Terms and Definitions References Applicable Documents Reference Documents Standards SVF CONCEPT Industrial Team Responsibilities SVF Functional Description MDVE Construction Kit SVF Architecture Core EGSE Real Time Simulator [RTS] On-Board Computer Simulator SVF REQUIREMENTS General Requirements Validation of AOCS Software Validation of Data Handling Software Support to On-board Software Development Section Deleted Support to Validation of non- AOCS Units Overall Function and Performance Interface/Tool Requirements Real Time Capability Design Implementation Physical Software Interfaces between SVF Elements Interfaces with the OBSW Development Environment Data Import and Export QUALITY ASSURANCE...16 whole or in part be reproduced, copied, or communicated to any person without written permission from the owner.

4 Page 4 of INTRODUCTION 1.1 Scope This specification defines the top level requirements for the on-board Software Validation Facility (SVF) for LISA Pathfinder. Pending the issue of the MDVE Implementation Plan [RD-01], this document is currently released at for PDR comment and may be updated accordingly. A Design Specification for the SVF will be generated in response to these requirements, which will take into account other information including the overall MDVE plans [RD-01] and [RD-02], pertinent interface definitions, the LISA-PF Packet Utilisation Standard [SD-03] and other design-impacting documentation.

5 Page 5 of Terms and Definitions LISA PF Satellite Database (SDB) Automated Procedures CCS C&C messages C&C reply Core EGSE (see CCS) The SDB contains all telecommand and telemetry definitions. It also contains the definition of all calibration functions and all limits for telemetry monitoring. Automated procedures (AP's) are programs executed by the core EGSE allowing the sending of telecommands and C&C messages and evaluation of the returning telemetry and simulator TM. (Open Centre) Central Check-out System used for core EGSE Commands sent by the core EGSE to RT Simulator or the OBC Simulator or a SCOE or the TM/TC GMFE. C&C messages are transported as CCSDS packets containing command strings. Note: Telecommands are not C&C messages. A typical example of C&C messages usage is the injection of error symptoms in simulated equipment in order to test the FDIR functionality of the OBSW. Response sent to the core EGSE upon reception of a C&C message Check-Out and Test System. It gives the user full control of automated ground testing and test result evaluation. Its responsibilities include: o o o o o o assembly of telecommands and C&C messages disassembly of telemetry and Simulator TM monitoring and dynamic visualisation of telemetry storage and administration of test configurations and test results storage and administration of a database including TM/TC definitions, monitoring limits and calibration coefficients execution of test automated procedures Engineering databases GMFE HPC Instance/Model MDVE Model OBC Simulator TM OBC-Simulator On-Board TC On-Board TM o graphical user interface The LISA-PF Satellite DB, CAIE-DB, Simulation TM-DB, and the Simulation Parameter DB are called the engineering databases. In the LISA-PF project all engineering database are stored in MS-Access format. Generic Modular Front Ends are units allowing to connect the Onboard Computer (OBC) with the core EGSE or the RT Simulator. The interface towards the core EGSE is a local area network (LAN), towards the RT simulator it is a VME bus. High Priority Command For each simulated equipment type, there will be one model in the Real time simulator defining the algorithm and the data interface of the simulation. Each existing equipment is represented by one instance of a model. The values of the model parameters can be different for each instance. Model-based Development and Verification Environment. This is a softwarebased environment for design verification, OBSW verification and integration testing of the spacecraft. See Instance. Simulator TM is sent from the simulated OBC towards the core EGSE. The OBC simulator models the complete onboard computer (OBC) allowing to execute the unmodified on-board software image on an ERC32 emulator, which forms the central part of the OBC simulator. These are commands sent from the OBC towards S/C units. On-Board TC can be direct I/O commands (e.g. HPC) as well as words on the MIL 1553 bus, or RS422 type. The latter can be identical to the telecommands sent from ground, but need not necessarily be in all cases. Very often one telecommand from ground will be translated into a series of On-Board TCs by the OBC OBSW. Data transferred from the S/C units towards the OBC. On-Board telemetry can be

6 Page 6 of 18 RT Simulator SCOE Simulation Parameter Database (SP-DB) Simulation TM Database (STM-DB) Simulator Configuration Files (XML files) Simulator TM SVF System Simulator Telecommand Telemetry transferred to the OBC via direct I/O (example thermistor read outs), serial lines or via MIL 1553 bus. The latter can be identical to the telemetry sent to ground, but does not need to be in all cases. Typically the OBC OBSW will collect all On- Board telemetry and assemble telemetry for the ground station. The Real Time simulator models spacecraft environment condition dynamics and all equipments except the Onboard Computer (OBC). The simulation is synchronized to an external time signal, which is provided by the real or simulated Onboard Computer Set of (electronic, magnetic, optical, etc.) equipment to stimulate and/or simulate the S/C s interfaces like sensors and actuators and/or other units (e.g. sun, batteries,...) Simulation Parameter Database (SP-DB) contains all data used to parameterize the MDVE software models. Typical examples are power consumption, heat dissipation etc. in engineering values. This database is also used to define, which parameters shall be accessible via the simulator TM. The Simulation TM Database (ST-DB) contains definitions of simulator specific telemetry, using the same table definitions as the L-SDB The RT simulator and the OBC simulator are configured at compile-time and/or start-up via ASCII input-files wrt. the following information: - TM/TC Definitions - Calibration Function Definition - Simulator TM Definition - On-Board TM/TC - Accessibility of Simulator Variables These input files are addressed as Simulator Configuration Files. Their format follows the XML standard. The simulators (both OBC Sim and RT Sim) can be commanded from the core EGSE via C&C commands. Such commands are acknowledged back to C&C via an acknowledge. If parameter value queries were included in the C&C command a C&C reply furthermore is generated containing the queried value. Besides that the simulator can send cyclical telemetry about the internal status of numerics or models to the core EGSE. This simulator TM is not to be confused with S/C telemetry additionally modelled by the OBC Simulator. Both S/C TM and the Simulator TM follow the same packet format standards, so that all TM packet contents can be evaluated by EGSE automated procedures. For simulator TM the parameter sets transmitted can be defined in so-called SID definitions. Multiple SID definitions can exist in parallel and can be activated on demand. Software Verification Facility Used for the verification and validation testing of the OBSW, using an OBC emulation (or OB processor board) with flight software, and an SVF controller MMI Synonymous to Real Time Simulator in some drawings and documents Commands, which can be sent from the ground segment (or on-board systems) towards the spacecraft. Data, which can be sent from the spacecraft to the ground segment

7 Page 7 of References Applicable Documents The following publications form a part of this document to the extent specified herein. Unless an issue is quoted for a document, the current issue is deemed to apply. When an issue is quoted, that issue and no other must be used. [AD-01] LISA Pathfinder Software Product Assurance Requirements for Subcontractors S2.SYS.RS Reference Documents The publications listed below contain background information relating to the subjects addressed. [RD-01] [RD-02] [RD-03] LISA-PF MDVE Implementation Plan TBD LISA-PF MDVE Design and Development Plan S2.ASU.DVP.2001 MDVE / EGSE Internal Interface Control Document TBD Standards The following standards form a part of this document to the extent specified herein. Unless an issue is quoted for a document, the most recent issue is deemed to apply. When an issue is quoted, that issue and no other must be used. [SD-01] [SD-02] [SD-03] Packet Telemetry Standard ESA PSS Packet Telecommand Standard ESA PSS LISA-PF Packet Utilisation Standard S2.SYS.ICD.2001

8 Page 8 of SVF CONCEPT 2.1 Industrial Team Responsibilities EADS Astrium Ltd is overall LISA-PF prime contractor responsible for the LISA-PF system design. Of relevance to the SVF, EADS Astrium Ltd is responsible for the definition, development and validation of the AOCS functions and the satellite bus electrical equipment. In collaboration with SciSys, EADS Astrium Ltd also has responsibility for the OBSW specification and (this document) the SVF user requirements. EADS Astrium GmbH is responsible for the MDVE (see below) and the design and development of the SVF. MDVE documentation [RD-01 and RD-02] will detail the logistics of when SVF facilities are required by the relevant parties as part of the overall MDVE philosophy for the LISA-PF project. It is anticipated that, as a minimum, an SVF will be required by EADS Astrium Ltd (as part of the overall MDVE), SciSys (in support of OBSW verification and validation) and EADS Astrium GmbH (the developers of the SVF but also users in the context of the LTP simulator development). The SVF could also be used to support complementary testing of the OBSW as part of the ISVV programme. In order to enable tracing and repeatability of observations from software related testing by the various users, a common SVF design shall be employed. 2.2 SVF Functional Description MDVE Construction Kit The SVF facilities for LISA-PF form part of the Model-based Development and Verification (MDV) process, a standard approach which has been developed by EADS Astrium GmbH for current and future spacecraft developments. EADS Astrium GmbH has established a modular infrastructure which shall be used to constitute all test configurations needed to implement the MDV process. This is referred to as the Modelbased Development and Verification Environment (MDVE) - a construction kit whose building blocks can be combined as appropriate for integration and test purposes. Figure shows the MDVE elements represented as boxes, linked together via a Local Area Network. The figure also shows the on-board computer breadboard and other satellite units in the loop. The box in the upper left hand corner represents the Software developers' Software Development Environment (SDE), which optionally can be brought into the loop for software debugging purposes. The SDE is not part of the MDVE. The MDVE may grow incrementally, but always makes use of the same set of satellite data bases as the binding data source throughout the entire life-cycle.

9 Page 9 of 18 Debugging I/F O/B Computer S/C Units SDE (not part of MDVE) O/B S/W SDE MMI GMFE Sim. Front End VME Bus I/Fs Serial I/Fs Analog I/Fs Digital I/Fs special I/O GMFE Power Front End LCL/FCL Power Supply TM/TC I/F Baseb. Proc. FEE Controller GMFE TM/TC Front End TM/TC FE MMI SCOE s / PL EGSE Stimulus Feedback Equipment OBC Simulator OBC Simulation Kernel Processor Emulation OBC H/W models PCI Real Time Simulator VME RTS Kernel Simulation Models (Units, S/C, Environm.) Core EGSE C/O Applications (DB, AP s, LIB s Kernel extensions C/O Kernel local MMI OBC Sim MMI OBC Sim. Computer RTS Computer RTS MMI MDVE Operator MMI Core EGSE Computer SCOE / PL EGSE Controller MDVE Local Area Network Figure : The MDVE Construction Kit SVF Architecture Figure shows the architecture for the SVF set up from the MDVE construction kit. Note that the SVF employs an OBC computer simulator - a numerical representation of the target system. SDE (not part of MDVE) O/B S/W SDE MMI OBC Simulator OBC Simulation Kernel Processor Emulation OBC H/W models PCI VME Real Time Simulator RTS Kernel Simulation Models (Units, S/C, Environm.) Core EGSE C/O Applications (DB, AP s, LIB s Kernel extensions C/O Kernel OBC Sim MMI OBC Sim. Computer RTS Computer RTS MMI MDVE Operator MMI Core EGSE Computer MDVE Local Area Network Figure : SVF Equipment Architecture

10 Page 10 of Core EGSE Operation of the SVF is under the control of the core EGSE acting as the central control system for the real time simulator, the onboard computer simulator and the on-board software under test. The core EGSE for the SVF is of the same type and standard as those used for the extended RTB test benches and the satellite EGSE, so that databases and test scripts can be exchanged between the different scenarios. The core EGSE connects to the OBC simulator and the real time simulator via a local area network. Besides standard links such as file transfer between the core EGSE and peripheral elements, there are two specific types of communication: monitoring and control of the simulators and routeing of telemetry and telecommands from / to the OBC simulator. All communication both for monitoring and control of the test environment and the command and telemetry to / from the on-board equipment shall be based on CCSDS packets. The core EGSE will provide standard functions for the preparation, execution and reporting of tests, with the main functions listed below: preparation phase: support preparation of automated procedures import / population of the TM/TC and local AIT database locally or by import configuration of TM/TC operator displays ( e.g. alphanumeric and graphic synoptics) preparation of test sessions including data consistency checks execution phase: manual command and system control execution of automated procedures generation of TC packets or CLTU s to the OBC simulator processing of TM packets or transfer frames from the front end monitoring and control of the front end and the simulator visualisation of telemetry raw data and processed on-line telemetry data evaluation and monitoring data archiving reporting / evaluation phase: data retrieval according to user selectable criteria replay of test sessions off line data analysis for performance prediction, failure analysis etc The core EGSE will support the PUS with the project specific implementations as defined in the LISA Pathfinder Packet Utilisation Standard [SD-03]. In addition to the standard functions listed above, the core EGSE provides software for the data consistency checking of telemetry down linked via the X-band transmission chain (which will include simulated or real payload telemetry). The core EGSE checks the X-band telemetry for consistency with the simulated data Real Time Simulator [RTS] The RTS will include models of the spacecraft units, the payload, the spacecraft dynamics and the space environment. The accuracy and completeness of the unit models will depend on the test objectives, which primarily are to validate the flight software. The functional and performance behaviour of the spacecraft units will be mimicked to the extent necessary to stimulate the flight software. Generally, full functional and performance modelling of the AOCS sensors and actuators will be required to enable closed loop testing. For this purpose, a high fidelity simulation of the spacecraft dynamics and the interaction with the space environment will be needed. Dynamic simulations of on-board equipments will be required in support of verification of the more dynamic functions of the data handling part of the OBC software (eg: on-board command execution verification). For other functions performed by the data handling software, more simple communication models may be employed, for example to provide predefined telemetry to and accept commands from the OBC. Generally, all models will be capable of being upgrading if necessary to provide a fully functional S/C simulator, as may be required for the purposes of mission operation support.

11 Page 11 of 18 The real time system simulator will be operable under control of the core EGSE by exchange of monitoring and control messages in the CCSDS packet format via the LAN interface. These messages will include the initialisation and setting of operation parameters of the simulator, as well as the access to the TM and TC parameter ports of the equipment communication models On-Board Computer Simulator The OBC simulator is based on a processor chip instruction set emulator, and models the real OBC hardware to the extent required to allow the real onboard software runtime code to be loaded and executed. The OBC Simulator will reflect: H/W modules of the real OBC hot and cold redundancy of the OBC H/W modules interfaces between OBC modules interfaces between OBC and S/C equipment cross coupling of all relevant interfaces The OBC Simulator will allow: monitoring of interfaces (e.g. CPU load) monitoring of modules (e.g. register contents) setting of module parameters (e.g. characterisation data) simulation of initialisation and boot processes setting of system presettings (e.g. OBT and elapsed time) loading, updating, patching and dumping of the OBC software injection of failure events into the relevant OBC modules all OBC sourced TLM parameters to be provided real-time code execution, either free running or synchronised by a simulated clock A specific item to be included in the OBC simulation is the mass memory function for storage of the payload data and the S/C housekeeping data. Modelling of this is required to validate the instrument control and data handling functionality of the OBC. In order to manage the command and telemetry handling from the core EGSE with an identical protocol as is used for the extended RTB test benches and the satellite EGSE, the OBC simulator will include a simulation of the TM/TC front end communication interface.

12 Page 12 of SVF REQUIREMENTS 3.1 General Requirements SVFR: <3.1-10> SVFR: <3.1-20> SVFR: <3.1-30> SVFR: <3.1-40> SVFR: <3.1-50> SVFR: <3.1-60> SVFR: <3.1-70> SVFR: <3.1-80> SVFR: <3.1-90> SVFR: < > SVFR: < > SVFR: < > The SVF shall be compatible with the Packet Utilisation Standard defined in [SD-01] and [SD-02] All tests shall be performed without flight hardware. All tests shall be performed on a facility with high fidelity simulation of the target processor (ERC32) and the target processor environment (Interfaces). For error analysis the test environment shall provide software source level debugging functionality. All tests shall be performed using test scripts / automated test procedures. All tests shall be repeatable, automatically. Test results shall be logged and shall be comparable with earlier test runs. The SVF shall be portable, i.e. not depend on local services. The SVF shall be network compatible, i.e. allow remote access via TCP/IP for monitoring and test execution. The SVF shall be able to execute the binary executable onboard software (OBSW) without any simulator-specific code modifications. In order to enable tracing and repeatability of observations from software related testing by the various users, a common SVF design shall be employed. The SVF operator workstations shall consist of 2 computers with dual displays 3.2 Validation of AOCS Software SVFR: <3.2-10> SVFR: <3.2-20> SVFR: <3.2-30> SVFR: <3.2-40> The SVF shall permit the validation of the AOCS-related algorithms implemented in the on-board software in open and closed loop mode. The SVF shall support the development and pre-validation of AOCS related check-out procedures and databases to be used in the AOCS extended RTB test bench and in the satellite AIT program The SVF shall support the development and validation of AOCS-related flight operations procedures The SVF shall support the validation of AOCS-related on-board control procedures (OBCP s) 3.3 Validation of Data Handling Software SVFR: <3.3-10> SVFR: <3.3-20> SVFR: <3.3-30> SVFR: <3.3-40> The SVF shall permit the validation of the data handling software including all PUS services, types and subtypes as defined in [SD-03] The SVF shall allow the validation of the instrument control functions of the OBSW, in particular the LTP processing and the DRS data handling The SVF shall support the validation of the payload science data handling functions of the OBSW The SVF shall support data consistency verification of science telemetry versus simulated payload data

13 Page 13 of 18 SVFR: <3.3-70> SVFR: <3.3-80> SVFR: <3.3-90> The SVF shall allow validation of on-board autonomy functions implemented into the OBSW including failure detection isolation & recovery (FDIR) The SVF shall support the preparation and validation of on-board control procedures (OBCP s) The SVF shall support the preparation and validation of flight operation procedures 3.4 Support to On-board Software Development The SVF shall be used at the on-board software contractor s premises to support failure analyses and anomaly investigations. For this purpose the following requirements shall be met: SVFR: <3.4-10> SVFR: <3.4-20> SVFR: <3.4-30> SVFR: <3.4-40> SVFR: <3.4 50> It shall be possible to install and rerun automated procedures from all SVF instances and from the extended RTB test benches and the satellite AIT on the SVF located at the OBSW contractor site It shall be possible to port the test result database or parts of it from all the SVF instances and from the extended RTB test benches and the satellite AIT onto the SVF located at the OBSW contractor site It shall be possible to run on the OBSW contractor s SVF a playback of recorded test sessions from other sites The SVF shall support tracing of simulated physical parameters and high level telemetry and telecommand definitions to the corresponding OBSW parameters and variables The SVF shall support the injection of hardware and software faults into the OBSW to allow verification of failure detection mechanisms. This should include the omission and spurious generation of internal and external processor traps, and the ability to modify internal software parameters to erroneous values at arbitrary points during the OBSW execution. 3.5 Section Deleted

14 Page 14 of Support to Validation of non- AOCS Units Besides AOCS validation, the SVF will be used to validate the instrument control S/W and the data handling. SVFR: <3.6 10> The SVF shall support the validation of the following simulation models: The LTP instrument The DRS instrument The X-Band system The PCDU The thermal behaviour The on-board electrical power network modelling The mass memory behaviour 3.7 Overall Function and Performance SVFR: <3.7 10> SVFR: <3.7 20> SVFR: <3.7 30> SVFR: <3.7 40> SVFR: <3.7 50> SVFR: <3.7 60> SVFR: <3.7 70> SVFR: <3.7 80> SVFR: <3.7 90> SVFR: < > SVFR: < > SVFR: < > SVFR: < SVFR: < SVFR: < The SVF shall allow source level debugging, i.e. stepwise execution, breakpoints, watch and trace points, while still connected to the S/C simulator environment. The SVF shall support all phases of software test and verification including error reproduction and analysis after software delivery. The SVF shall support open an closed-loop simulation for the AOCS and Data Handling software. TC Handling The SVF shall include facilities for TC generation. The SVF shall include facilities for TC logging in binary format and engineering format. The SVF shall be able to read TC s from the Satellite Database. SVF shall be able to input TCs at rates that will exceed those that can be handled by the OBS. The SVF shall include facilities to generate and handle HPC commands. It shall be possible to send TC with an invalid format. TM Handling The SVF shall include facilities for TM handling. The SVF shall include facilities for TM on-line display in binary format and programmable engineering format. The SVF shall be able to decode TM based on the Satellite Database The SVF shall be able to log all TM s in TM log-files. The SVF shall support logging levels in order to support TM data stream filtering. The SVF shall provide features to extract a selection of data from the test result database into an external format.

15 Page 15 of 18 SVFR: < SVFR: < SVFR: < SVFR: < SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > SVFR: < > As a minimum the following formats shall be supported: EXCEL *.csv format (ASCII format) SVF shall be able to accept TM s at rates that will exceed those that can be generated by the OBS. Target Environment Simulation The simulation shall be representative at protocol level of the actual hardware being interfaced. It shall be possible to introduce any possible protocol or hardware malfunction into the simulation of the OBC interfaces. TM/TC events shall be synchronised with the interface simulation. MMI / SVF control The SVF shall run on-line or off-line (by animation of test sessions) in batch mode. Each test session/run shall have a unique identifier. SVF control commands shall be accepted every time. The SVF shall be able to execute automatic test scripts. The SVF shall be able to log any TM/TC as well as outputs generated by the test scripts into test result files. The SVF MMI shall support software loading into the ERC32. The SVF MMI shall support timing control and execution time display. The SVF shall display its own status information on a graphical display in engineering formats. Any relevant data for test execution, verification and set-up shall be accessible from the MMI. Sensor / actuator interfaces The SVF shall read a selectable set of sensor data from files to be used for open loop AOCS tests. The SVF shall log a selectable set of actuator data in files. 3.8 Interface/Tool Requirements SVFR: <3.8-10> SVFR: <3.8-20> SVFR: <3.8-30> The SVF shall have an interface to the source level debugger. The SVF shall interface to the common TM/TC database for using TC and TM structure definitions. All surrounding OBC hardware shall be emulated at protocol level. 3.9 Real Time Capability SVFR: <3.9-10> The SVF shall simulate the execution of the application software in simulated real time and provide real-time performance/task scheduling information.

16 Page 16 of Design Implementation The following requirements cover the design of the SVF as a whole Physical SVFR: < > The SVF elements shall as far as possible be mounted into a standard 19" rack Software SVFR: < > The check-out software for the SVF operation and tests shall be designed for easy merging and reuse at extended RTB test benches and for satellite AIT Interfaces between SVF Elements SVFR: < > The LAN communication interface between EGSE / MDVE elements shall be as defined in the MDVE Internal Interface Control Document [RD-03] Interfaces with the OBSW Development Environment SVFR: < > The SVF shall support standard data exchange mechanisms (E.g. FTP) for loading OBSW executable code from the software development environment Data Import and Export SVFR: < > The SVF shall provide capabilities for data exchange between different sites via pubic data networks (e.g. Internet, ISDN, FTP etc.) for loading OBSW executable code from the software development environment 4. QUALITY ASSURANCE Quality assurance activities applied to the development of the SVF elements and the completely integrated SVF will be in accordance with the relevant sections of [AD-01].

17 Page 17 of 18 INTENTIONALLY BLANK

18 Page 18 of 18 DOCUMENT CHANGE DETAILS ISSUE CHANGE AUTHORITY CLASS RELEVANT INFORMATION/INSTRUCTIONS Initial Issue for SRR 10 May S2CA083 - Second issue for PDR DISTRIBUTION LIST INTERNAL EXTERNAL Astrium LPF team SciSys LPF team Configuration Management Library Luisella Giulicchi (ESA) Paolo Maldari (ESA)