Post on 28-May-2022
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
On Board Software
November 2014
November 2014 On Board Software Overview for ULg
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● On Board Software Properties
● On Board Software Environment
● On Board Software Dependability
● On Board Software Criticality
On Board Software > Characteristics
November 2014 2 On Board Software Overview for ULg
OBSW Characteristics
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● System-software co-engineering: Software is part of the System. Software properties must be derived from System properties.
● End-to-end system response time will result into a software schedulabity property.
● System availability property will result into software FDIR mechanisms that must have a particular behaviour.
● System performance property may result in a software numerical accuracy property.
On Board Sofgtware > Characteristics > Propoerties
November 2014 3 On Board Software Overview for ULg
OBSW: Properties
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Embedded Software Cross Development Environment, bounded Memory Footprint and Processor Consumption
● On Board Software Single Event Effects, (Upset, Latch Up), Memory Scrubbing
● Real Time Software Processor load, scheduling issues, soft and hard deadlines
● Deterministic Software No Dynamic thread creation or memory allocation, budget and schedulability
● Remote Software Need for autonomy
● Critical Software (see further down)
Possible catastrophic consequences of failure
● Dependable Software (see further down)
Need for high Reliability, Availability, Maintainability and Safety
O Board Softyware > Characteristics > Contraints
OBSW: Constraints
November 2014 On Board Software Overview for ULg 4
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: Dependability
November 2014 On Board Software Overview for ULg 5
On Board Software > Characteristics > Dependability
RAMS
•Reliability: continuity of correct service.
•Availability: readiness for usage.
•Maintainability: easiness of repair/upgrade.
•Safety: non-occurrence of catastrophic failure
Strategies
•Fault Prevention avoidance and reduction of fault causes
•Fault Tolerance avoidance and reduction of fault consequences
•Fault Removal removal of fault occurrences
•Fault Forecasting prediction of behaviour in presence of faults
FDIR
•Fault Detection e.g. through monitoring
•Fault Isolation determination of the cause
•Fault Recovery e.g through redundancy
Achieving mission objectives and ultimate mission success relies on dependability of the space Systems.
Analysis
•FMECA:
Failure Mode Effects and Criticality Analysis
•FTA: Fault Tree Analysis
•FHA Functional Hazard Analysis
•HSIA: Hardware Software Interaction Analysis
•SCCFA: Software Common Causes Failure Analysis
•SWCA: Software Criticality Analysis
FDIR is imperative to guarantee a dependable and autonomous system with a minimal risk of ruinous failure
•Integrity Maintenance of data consistency
•Security Non disclosure of unauthorized info
•Certifiability Ability to get stamp from certification body
As software plays more and more a prominent role in space systems, its contribution to the overall system dependability becomes a vital aspect of system development.
Troubles
•Error: A wrong or missing human action or thought
•Fault: An incorrect step, process or data definition in a program
•Failure: The inability of the software to perform its required functions.
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: Criticality
November 2014 On Board Software Overview for ULg 6
On Board Software > Characteristics > Criticality
Software that if not executed or if not correctly executed or whose anomalous behaviour could cause or contribute to a system failure resulting in :
A: Catastrophic Consequences
Loss of Life, life threatening, personnel injuries, permanently disabling injury or occupational illness, Loss of an element of an interfacing manned flight system. Damage to other equipment. Loss of launch site facility facilities or loss of system. Severe detrimental environmental effects.
B: Critical
Consequences
Permanent or non-recoverable loss of the satellite’s capability to perform its planned mission Temporarily disabling but not life-threatening injury or occupational illness. Major damage to flight system or loss or major damage to ground facilities. Major damage to public or private property or major detrimental environmental effects.
C: Major
Consequences
Negligible or minor effect on the satellite’s mission and operability A detailed definition is left on a project by project basis and reported in its risk policy. Example is Mission Simulation Software
D: Minor
Consequences
A detailed definition is left on a project by project basis and reported in its risk policy. Example is Test Software
Note: In the DO-178-C (Software Considerations in Airborne Systems ), the Design Assurance Level (DAL) is determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers (catastrophic, severe/hazardous, major, minor, no effect).
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● On Board Software Phases
● On Board Software Development Lifecycle
● On Board Software Development Standard
● On Board Software Documentation
November 2014 7 On Board Software Overview for ULg
OBSW : Process On Board Software > Process
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: Phases
November 2014 On Board Software Overview for ULg 8
On Board Software > Process > Phases
Key Decision
Points
FORMULATION IMPLEMENTATION
Major Reviews
Project
Phases Concept of Operations Mission Needs Feasibility Studies
Concept &Technology Development
Preliminary Design
& Technology Completion
Final Design &
Fabrication
System Assembly,
Test, &
Launch
Closeout Operations & Sustainment
A B C D E F Pre-A
Mission Concept Review
Systems Requirements Review
Mission/System Definition Review
Critical Design Review
Systems Integration Review
Operational Readiness Review
Flight Readiness Review
Post Launch Assessment Review
Decommissioning Review
Preliminary Design Review
Independent Cost Estimates
Major Project Reviews Precede Each Key Decision Point
A C D E B F
OPERATION
Launch
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: Lifecycle
November 2014 On Board Software Overview for ULg 9
On Board Software > Process > Lifecycle
System and Mission Requirements
Software Specification
Detailed Design
Coding
Preliminary Design
Validation Test
Integration Test
Unit Test
Acceptance Test
SDD-AD, ICD’
SRS, ICD
SDD-DD
VTR, VCD
ITR
Source Code, Executable, Makefiles, Scripts
SRR
PDR
(DDR)
CDR (TRR/TRB/DRB)
PMP, PAP, CMP, SDP, SVVP
SSS,IRS,OCD
RFI, RFQ, RFP, ITT, SOW
UTR
SUM,COM, SPS
QR (TRR/TRB/DRB)
AR (TRR/TRB/DRB)
ATP
VTP
ITP
UTP
Phase A
Phase B
Phase C
Phase D
Phase E
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Verification Validation
● All along Development ● Methods
● Reviews ● Peer Review ● Cross Reading ● Independent Software
Verification and Validation
● Analysis ● Static Analysis ● Schedulability Analysis
● Tools
● Software Engineering Tools (e.g. static code analyzer)
● At end of Development ● Methods
● Test Campaign ● Unit Testing (Code Coverage)
● Integration Testing (Interface)
● Validation Testing (Functionality)
● Requirement baseline ● Software Specification
● Tools
● Software Validation Facilities ● Hardware Models ● Numerical Test Benches ● Hybrid Facilities
OBSW: Verification & Validation On Board Software > Process > Verification and Validation
November 2014 10 On Board Software Overview for ULg
Supported as far as possible by Formal Methods
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW : Standards
November 2014 On Board Software Overview for ULg 11
On Board Software > Process > Standards
European Cooperation for Space Standardization
Reports: Blue: Recommended Standards Magenta: Recommended Practices Green: Informational Reports Orange: Experimental or ongoing research Yellow: Record, but not Historical Silver: Historical
Standards: Management Standards ECSS-M-XXX Product Assurance Standards ECSS-Q-XXX Engineering Standards ECSS-E-XXX
Consultative Committee for Space Data Systems
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW : Documentation
November 2014 On Board Software Overview for ULg 12
Software configuration management plan (DRD in ECSS-M-ST-40)
Software review plan
...
Software system specification
Software interface requirements document
...
Software design document Software configuration file (DRD in ECSS-M-ST-40) Software release document
... Software user manual
Maintenance plan (without DRD) Migration plan (without DRD) ...
PAF Product Assurance
File
TS Technical
Specification
DJF Design Justification
File
OP Operational
Software product assurance plan Software product assurance milestone report
Software product assurance requirements for suppliers ...
Software requirements specification Interface control document ...
Software validation plan Software verification plan Software unit and integration plan
...
Software reuse file
Operational plan
Operational testing specification ...
Software development plan
MF Maintenance
File
MGT Management File
DDF Design Definition
File
Software validation specification
Software verification report
RB Requirements
Baseline
Related file DRL item
(e.g. Plan, document, file, report, form,
matrix)
DRL item having
a DRD
SRR PDR CDR QR AR ORR
RB Software system specification (SSS)
Interface requirements document (IRD)
Safety and dependability analysis results
for lower level suppliers
TS Software requirements specification (SRS)
Software interface control document (ICD)
DDF Software design document (SDD)
Software configuration file (SCF)
Software release document (SRelD)
Software user manual (SUM)
Software source code and media labels
Software product and media labels
Training material
DJF Software verification plan (SVerP)
Software validation plan (SValP)
Independent software verification &
validation plan
Software integration test plan (SUITP)
5.2 Software related system requirement
process
5.4 Software requirements and architecture
engineering process
5.5 Software design & implementation
engineering process
5.6 Software validation process
5.3 Software management process
5.7 Software delivery and
acceptance process
5.7.2 Software delivery
and installation
5.7.3 Software acceptance
5.8 Software verification
process
5.8.2 Verification process
implementation
5.8.3 Verification activities
5.5.2 Design of software items
5.5.3 Coding and testing
5.4.2 Software requirements analysis
5.4.3 Software architectural design
5.6.2 Validation process
implementation
5.5.4 Integration
5.6.3 Validation w.r.t. the technical
specification
5.6.4 Validation w.r.t. the requirements
baseline
5.2.2 Software related system
requirements analysis
5.2.3 Software related system
verification
5.2.4 Software related system
integration and control
5.2.5 System requirement review
5.10 Software maintenance
process
5.9 Software operation process
5.9.2 Process implementation
5.9.3 Operational testing
5.9.4 Software operation support
5.9.5 User support
5.10.2 Process implementation
5.10.3 Problem and
modification analysis
5.10.4 Modification implementation
5.10.5 Conducting maintenance
reviews
5.10.6 Software migration
5.10.7 Software retirement
5.3.2 Software life cycle
management
5.3.3 Joint review process 5.3.7 Interface management
5.3.8 Technical budget and
margin management
5.3.4 Software project
review description
5.3.5 Software technical
reviews description
5.3.6 Review phasing
5.4.4 PDR
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Interfaces and Data Flows
● Functional Architecture
● Static Architecture
● Dynamic Architecture
● Deployment Architecture
On Board Sofwtare > Architecture
November 2014 13 On Board Software Overview for ULg
OBSW Architecture
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Interfaces & Data Flows
November 2014 On Board Software Overview for ULg 14
On Board Software > Architecture > Interfaces
OBSW
Telecommands
•High Priority commands Hardware
•Nominal commands
Software
•Macro commands Expanding
•Time tagged commands
Scheduling
Telemetries
•Housekeeping (Platform & Payload) Temperature, Pressure, Voltage and Current, Statuses •Science Data (Payload) e.g. Raw or compressed images
GND Control Center
Space Ground Interface
Te
lem
etr
y
Te
leco
mm
an
d
PF Equipments
Platform Interfaces
PL Instruments
Payloads Interfaces
Science Data
Control
Command
Command
Control
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Functional Architecture
definition of
● functional break down in
● functional modules and
● functional interfaces between these modules
On Board Software > Architecture > Functional Architecture > Principles
November 2014 15 On Board Software Overview for ULg
Functional Architecture (1/2)
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Functional Architecture (2/3)
November 2014 On Board Software Overview for ULg 16
On Board Software > Architecture> Functional Architecture > Variability
Mission
Operation
Avionics
Monitoring & Control Interfaces
Network
Processor
Mode Mgt
SYS SW
PL SW
PF SW
AOCS SW
DH SW
Processing
Commandability
Observability
Fault Mgt
Equipment Mgt
Processing
Telecommand Mgt
Telemetry Mgt
Fault Mgt
Components
Interaction Layer
Execution Platform
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Functional Architecture (3/3)
November 2014 On Board Software Overview for ULg 17
On Board Software > Architecture > Functional Architecture > Functional Breakdown
TM/TC Telemetry & Telecommand
space/ground communications or
communications between spacecraft
HK Housekeeping
Gathering, filtering and reporting of
on board acquired data
MON Monitoring
detection of on board events based on
ranges or thresholds or trends
OBT On-Board Time Management
For the synchronization of the on-board
clock with ground time,
FDIR Fault Detection Isolation and Recovery
for the on board software and system dependability
GNC/AOCS/ACNS Attitude and Orbit Control Software
Computes the actuators commands from the sensors measurement in
order to control the spacecraft attitude and position.
Control the propulsion system.
RF Radio Frequency Management
for the communications with ground
or with other sapcecrafts
e.g. through S-Band or X-Band links. CM Context Management
Saves the context (failure history buffer,
GNC states, OBSW patches, equipment
table, mission timeline) in case of
processor failure.
SM Storage Management
for the storage of TM in case of
Earth link unavailability
THERM Thermal Management
for the temperature control of the spacecraft
e.g. through thermal heater lines,
PWR Electrical Power Supply Management
distributes the power coming from the battery and
the solar arrays
and manages battery charge / discharge,
SADM Solar Array Drive Mechanisms Management
for the optimal alignment of a satellite's solar panels towards the Sun.
RDP/HRM Release, Deployment and Pyrotechnic Activation Management
for solar arrays/antenna deployment,
for propulsion arming sequence before firing, or
for specific needs like shield jettison or spacecrafts composites dispatching,
PL Payload Management
for scientific payload or
additional units
(very mission specific)
EQPT Equipment Management
for the maintain of the equipment table
as the reflect of the actual equipment
status, and the management of
equipment interface,
ACQ Data Acquisition
Acquisition of on board data
e.g. according to polling sequence table
and depending on mode
Note: interactions between functions are not depicted
SMGT Spacecraft Modes Management
handles the on-board system through the different
mission phases
defines the level of autonomy,
MMGT Mission Management
for the execution of the mission timeline
ETC … And Many Others
And many other functions depending on the platform bus and on the mission
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Static architecture deals with ● Functional Properties ● Static Decomposition ● Software Component Model
● Software is broken down ● in software components (aka modules, units or objects) ● with clear interface between them
● Components are organized (see slide 2/4)
● horizontaly in variability layers with coherent abstraction level and ● verticaly in functional chains with coherent functionality
● Component are functional units (see slides 2-3-4/4)
● That encapsulate functional services, ● that expose these services to other components through well defined interfaces, and ● that can be assembled together to build a software product
● Components are made up of (see slide 3/4)
● Algorithms, State Machines ● Data Structures
● Main design decision is (see slide 4/4)
● Central Data Pool vs ● Distributed Data Flows
● Main programming paradigms are ● Procedural programming vs ● Object Oriented programming (not used so far in on board software)
On Board Software > Architecture > Static Architecture > Summary
November 2014 18 On Board Software Overview for ULg
Static Architecture (1/4)
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Static Architecture (2/4)
November 2014 On Board Software Overview for ULg 19
On Board Software > Architecture > Static Architecture > Generiic Structure
Platform Dependent
Avionics Dependent
Operation Dependent
Mission Dependent
Thermal Mgr
Power Mgr
FDIR AOCS SC Mgr
…
INTERFACES MODULES
VARIABILITY LAYERS
Coherent Abstraction
Level
FUNCTIONAL CHAINS
Coherent Functionality
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Static Architecture (3/4)
November 2014 On Board Software Overview for ULg 20
On Board Software > Architecture > Static Architecture > Component
COMPONENT MODULE
UNIT OBJECT
Provided Interface
Required Interface
Functions Procedures
Methods
Data Structures
State Machines
Algorithms
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Static Architecture (4/4)
November 2014 On Board Software Overview for ULg 21
On Board Software > Architecture > Static Architecture > Design Decision
VS
Central Data Pool Distributed Data Flow
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Component Model
November 2014 On Board Software Overview for ULg 22
Component
Container
Component
Container
Connector
Design Level Implementation Level
Functional Concerns (algo)
Non Functional Concerns (tasking, timing, config, init, security, …)
Platform Independent Model Platform Specific Model
Provided Interface Required Interface
Separation of Concern
Pairing up
Composition Reusability Replaceability
STATIC ARCHITECTURE
Execution Platform
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Dynamic Architecture deals with ● Non Functional Properties ● Computational Model ● Dynamic Behaviour
● Main concepts are (see slide 2/3)
● Tasks, Threads and Interrupts ● Scheduling, Processing Time and Priorities ● Communication and Synchronisation
● Main design decision is (see slide 3/3)
● Periodic/Cyclic/Synchronous/Time Driven/Polling vs ,
● Aperiodic/Sporadic/Asynchronous/Event Driven/Interrupts
On Board Software > Architecture > Dynamic Architecture > Summary
November 2014 23 On Board Software Overview for ULg
Dynamic Architecture (1/3)
Period, Offset, Minimum Inter Arrival Time, Priority, Deadline, Worst Case Execution Time
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Shared Resources (memory, inputs/outputs, …)
Shared Executable (reentrance of code …)
Scheduling Periodicity Priorities,
Preemption
Synchronisation Semaphores Mutexes Critical Sections
Execution Flow Execution Flow
Communications Pipes, sockets message queues, mailboxes, …
Several interrupts and periodic and sporadic tasks with different periods and priorities
Leading to possibly complex schedulability issues
Interrupts Hardware Interrupts Software Traps
Tasking Periodic Tasks
Tasking Sporadic Tasks
Dynamic Architecture: Concepts On Board Software > Architecture > Dynamic Architecture > At A Glance
November 2014 On Board Software Overview for ULg 24
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Computational Models
● RMA: Rate Monotonic Algorithm Static priority preemptive scheduling. Applies to cyclic jobs. Shorter cycle get higher priority
● DMA: Deadline Monotonic Algorithm Static priority preemptive scheduling. Applies also to sporadic jobs. Shorter deadline get higher priority
● EDF: Earliest Deadline First Algorithm Dynamic priority preemptive scheduling. process closest to its deadline get highest priority
● RCM: Ravenscar Computational Model Fixed-priority preemptive system with tight restrictions on tasking and synchronisation such as priority ceiling that optimally bound priority inversion, to achieve lock-free mutual exclusion and to avoid deadlocks. Warrants static analysability of the source code and predictability of execution
● TSP: Time and Space Partitioning hierarchical superposition of two computational models : round robin scheduling of partitions and fixed priority scheduling of tasks within partitions
On Board Software > Architecture > Dynamic Architecture > Computational Models
November 2014 25 On Board Software Overview for ULg
Dynamic Architecture: Computational Model
See also Schedulability Analysis
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Proof of software schedulability
● Run Time Testing (how to prove exhaustivity?)
● Static Analysis (superior to testing)
● Selected Computational Model (see dynamic architecture)
● Implementation is assumed to comply to model
● Mathematical schedulability criteria
● Software Budget Report (estimated or measured)
● Processor utilization
● Worst Case Execution Times
November 2014 26 On Board Software Overview for ULg
Dynamic Architecture: Schedulability
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Formal Proof
Dynamic Architecture: Schedulability
November 2014 On Board Software Overview for ULg 27
On Board Software > Architecture > Dynamic Architecture > Schedulability
Architecture
Implementation
Validation
Static Analysis
Mathematical
Model
Execution
Measurements
Computational
Model
Compliant
Implementation
•Rate Monotonic Scheduling •Deadline Monotonic Scheduling
•Earliest Deadlin First •Ravenscar Profile
(See Dynamic Architectures)
Processor Utilization Worst Case Execution Time
(Based on realistic scenarios)
•Programming Model •Design and Coding Rules
•Code Generation
Schedulability Condition
Compliance to a selected Computational Model allows for Static Analysis and Formal Check of Schedulability Conditions, based on corresponding Mathematical Model fed by actual Measurement from execution of realistic scenarios.
To this respect, Static analysis is superior to testing, which faces exhaustivity issue in real-scale systems.
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Deployment Architecture deals with the Mapping ● of a logical architecture (software components) ● to a physical environment (hardware resources).
● Main concepts are ● Distribution ● Communication
● Main design decision is ● Centralised Architecture vs ● Distributed Architecture
On Board Software > Architecture > Deployment Architecture > Summmary
November 2014 28 On Board Software Overview for ULg
Deployment Architecture (1/2)
Consider also Multi Processor Multi Core Time and Space Partitioning
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Deployment Architecture (2/2)
November 2014 On Board Software Overview for ULg 29
A deployment architecture depicts the mapping of a logical architecture (software components) to a physical environment (hardware resources).
The physical environment includes the computing nodes, processors, memory, storage devices, and other hardware and communication devices
On Board Software > Architecture > Deployment Architecture > Concepts
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Reference Architecture
November 2014 On Board Software Overview for ULg 30
OBSW > Architecture > Reference Architecture > Big Picture
ComsI/F
GenericApplication
Services
DHS Support Package
Core Services
BSW & RTOS I/F
OBCPInterpreter
On BoardFile
System
PUS services
HKTMTC EVTMON
MEM
TIMESCHED
OBCPOBDS LDT
DataAcquisition
EVT SCHEDFS
DB
FCT
MSG
RTOS DriversBSP
STAT HEALTH
Applications
AOCS POWER THERMAL PAYLOADS
…MISSION
ComsI/F
GenericApplication
Services
DHS Support Package
Core Services
BSW & RTOS I/F
OBCPInterpreter
On BoardFile
System
PUS services
HKTMTC EVTMON
MEM
TIMESCHED
OBCPOBDS LDT
DataAcquisition
EVT SCHEDFS
DB
FCT
MSG
RTOS DriversBSP
STAT HEALTH
ComsI/F
GenericApplication
Services
DHS Support Package
Core Services
BSW & RTOS I/F
OBCPInterpreter
On BoardFile
System
PUS services
HKTMTC EVTMON
MEM
TIMESCHED
OBCPOBDS LDT
DataAcquisition
EVT SCHEDFS
DB
FCT
MSG
RTOS DriversBSP
STAT HEALTH
Applications
AOCS POWER THERMAL PAYLOADS
…MISSION
Applications
AOCS POWER THERMAL PAYLOADS
…MISSION
Applications
AOCS POWER THERMAL PAYLOADS…
Applications
AOCS POWER THERMAL PAYLOADS…
Lighweight On Board
Application Framework
Design Pattern (« a repeatable solution … »)
Middleware (« a connectivity service … »)
Common Services (« shared services … »)
Layered and Modular
Architecture
Mission Specific Applications
Generic Component
Platform Specific Components
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● PUS (being revisited)
● SOIS (is this really new?)
● OBCP (new standard)
● FDIR (on going study)
● CFDP
● FS
● …
On Board Software > Architecture > Reference Architecture > Building Blocks
November 2014 31 On Board Software Overview for ULg
Building Blocks
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Execution Environment
● On Board Processors
● Real Time Operating Systems
● Development Environment
● Modeling Environment
● Programing Language
● Production Environment
● Validation Environment
On Board Software > Environment
November 2014 32 On Board Software Overview for ULg
OBSW Environment
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Hardened Space Qualified processors 1990: 1750 – 16 Bits – 2 MIPS 2000 : ERC32 – SPARC V7 - 32 Bits – 20 Mhz – 14 MIPS 2010 : LEON – SPARC V8 - 32 Bits – Cache – Pipeline -100 Mhz – 84 MIPS Future: NGMP – Quad Core LEON
● Commercial of the Shelf e.g. Power PC 1600 MIPS but sensitive to SEEs
See Avionics Overview
On Board Software > Environment > Processorxs
November 2014 33 On Board Software Overview for ULg
OBSW Environment : Processors
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● RTOS: Real Time Operating Systems
● VxWorks (Commercial)
● RTEMS (Open Source)
● Linux RT (Not widely used … in OBSW)
● TSP: Time and Space Partitionning
● Hypervisor
● µKernel
On Board Software > Environment > Real Time Operating Systems
November 2014 34 On Board Software Overview for ULg
OBSW: Operating System
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Paradigm Shift ● From Programming to Modelling ● Model Based Software Engineering
● Modeling Domains ● Architecture Modeling, ● Data Modeling, ● Behaviour Modeling
● Modelling Languages ● UML, SYSML, AADL, AAML, SDL, …
● Model Verification ● Strong Syntax, Formal Verification
● Automatic Generation
On Board Software > Environment > Modeling
November 2014 35 On Board Software Overview for ULg
OBSW Environment: Modelling
ECLIPSE Integrated Development Environment (IDE) and Eclipse Modelling Frameworl (EMF)
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Languages ● C:
procedural language, widely used, poor expressivness but good control, well suited to system programming, efficient code but error prone
● Ada: strong typing, well suited to embedded and real-time programming, mainly used in launchers
● C++ : object oriented, based on C, less efficient due to object oriention, not used or poorly used on board so far
● Java : object oriented, interpreted language, under investigation, possibly for OBCP
● Assembler low level language, for specific usage
On Board Software > Environment > Languages
November 2014 36 On Board Software Overview for ULg
OBSW Environment: Programming
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW Environment : Production
November 2014 On Board Software Overview for ULg 37
On Board Software > Environment > Production
OBSW
Configuration
Files
ODE
Configuration
Files
User Manual Interface Control
Document
System
Data Base
Central
Configuration
Data Base
SVF
Configuration
Files
Production Tools
• Support Automatic generation of … Configuration Files and Documentation
• Allow for easy configuration
Centralised Database ● Contains …
On-board software configuration, Constant values, and Parameters useful for ground tasks, message queues, observable parameters, events, actions associated with events, default housekeeping, default monitoring, patch areas, Drivers commands, TC function ID’s (PUS 8, 1), Memory partitions, File partitions, On-board stores, Default on-board storage allocation, PUS services and sub-services, Types of the parameters in the PUS TC/TM, Error codes, Application ID …
● Ensure coherency between … the different outputs
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW Environment: Validation On Board Software > Environment > Validation
OBSW
Drivers
Applications
Data Handling Software
RF PWR AOCS
DHS PUS
DHS CORE
SYS MGT
TTM SIM DAM RECU
APP SVC
MPM
OBCP
FDIR
Generic SVF Component
Platform dependent SVF Component
Test Conducting
Sim
ula
tio
n
Co
ntr
ollers
Simulation Core
Environment
Graphical User
Interface
Script Language Interpreter
Integrated Symbolic Debugger
Instruction Set Simulator
Engine
Discrete Event &Time
Simulator Engine
Ground
Equipments
Communications
Memory Simulation
Marker/ Breakpoints/
Coverage
Processor Registers Simulation
ST GPS MM RW MT
SIM DAM RECU TTM
Instrum LYRA Distributed Simulation Interface
Configuration
Calibration
Test Conducting Script
Message Parsing &
Formatting
Synchro- nisation
MPM
RWM
Mu
lti
Co
ntr
ollers S
up
po
rt
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Modeling Exemples
● Modeling Definition
● Modeling Objectives
● Modeling Characteristics
● Modeling Methods
November 2014 39 On Board Software Overview for ULg
OBSW Modeling On Board Software > Modeling
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Modeling : Examples
November 2014 On Board Software Overview for ULg 40
On Board Software > Modeling > Examples
Software has the rare property that it allows us to directly evolve models into fully-fledged
implementations without changing the engineering medium, tools, or methods
The software model may evolve into the system it was
modeling in a seamless process.
non available
not lockedlocked
buffer ready
link available
not locked
set to unavailable
set to available
locked
start transfer
buffer ready
set to available
set to unavailable
/*! Note: This function is only called from the event manager sporadic activities. * Extraction of the event data is performed within EVTM_execute_sporadic_activities. */ TM_DECLARE_NEW_MESSAGE (TM_room, TM_ptr, TM_FIXED_SIZE + EVT_MAX_EVENT_DATA_LENGTH) uint32 data_size; uint8 * data_ptr = TM_get_data(TM_ptr); /*! Verify event_id input. It must be less than EVT_NB_EVENTS. Note that this only protects from table overflow: * This should indeed never happen as the data has been checked when it was put in the queue. * Therefore only return to avoid overflowing, no report is generated. */ if (event_id >= EVT_NB_EVENTS) { return; } /*! The event must be enabled for reporting: If the event id is disabled, return without generating a report. */ if (EVTR_config[event_id].reported == False) { return; } /*! Event data size is limited by the maximum event length. If the generation of this report would create * a telemetry packet with data size larger than EVT_MAX_EVENT_DATA_LENGTH, truncate to EVT_MAX_EVENT_DATA_LENGTH. */ data_size = sizeof(EVT_RID_t) + event_data_length; if (data_size > EVT_MAX_EVENT_DATA_LENGTH) { data_size = EVT_MAX_EVENT_DATA_LENGTH; } GU_memcpy( data_ptr , &event_id , sizeof(EVT_RID_t) ); data_ptr += sizeof(EVT_RID_t); if (event_data != NULLPTR) { GU_memcpy(data_ptr, event_data, data_size - sizeof(EVT_RID_t)); } /*! Generate the event by creating the corresponding service 5 packet. The PUS subtype (between 1 and 4) * is obtained from the EVTR_config configuration table. */ TM_create(TM_ptr, application_id, TMTC_ERS, EVTR_config[event_id].event_subtype, 0, /* data are already at the correct place */ data_size, ROUTE_GROUND_ID); TM_send_telemetry (TM_ptr, data_size + TM_FIXED_SIZE, True, False);
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● What is a Model?
● A model is a description of (part of) a system written in a well defined language. A well defined langauge is a language with a well defined form (syntax), and meaning (semantic), which is suitablefor an automatic interpretatiojn by a computer. (Anneke Kleppe et.al. « MDA Explained »)
● A formal representation of a function, behaviour and structure of the system we are considering. Expressed in an unambiguous language. (Chris. Raistrick et. Al. « Model Driven Architecture and Executable UML »)
● Models are an abstraction of the reality captured in a specific representation format i.e. diagram or language.
● A model is a simplification of something so we can view, manipulate, and reason about it, and so help us understand the complexity inherent in the subject under study. (Steve Mellor et. All « UML Distilled »)
● A simplification of a system built with an intended goal in mind: the model should be able to answer questions in place of the actual system. (J. Bézivin & O. Gerbé. « Towards a precise définition of the OMG/MDA Framework »)
● A model is a complex structure that represents a design artifact such as a relational schema, and interface definition (API), and XML schema, a semantic network, a UML model or an hypermedia document (Phil. Bernstein. « A Vision of Management of Complex Systems »)
● A model captures a view of a physical system. It is an abstraction of a physical system with a certain purpose; This purpose determines what is included in the model and what is relevant. Thus the model completely describes those aspects of the physical system that are relavant to the purpose of the model, at the appropriate level of detail. (OMG. « UML Superstructure »)
● A functional specification of the function, structure and/or behaviour of an application or system. (OMG. « MDA Guide »)
On Board Software > Modelling > Definitions
November 2014 41 On Board Software Overview for ULg
Modeling: Definition
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
●Objectives of Software Modeling ● To deal with complexity of systems development through
● Abstraction: Abstract a problem to focus on some particular points of interest and to improve understandability of a problem
• Iteration: Iterative modeling may be expressed at different level of fidelity
• Separation of Concerns: Possible set of nearly independent views of a model (“Aspect Oriented Modeling”)
• Domain Specific Language: To focus on specific domain expertise
• To minimize development risks through
• Through analysis and experimentation performed earlier in the design cycle
• Enable to investigate and compare alternative solutions
● To improve communication ...
• to foster information sharing and reuse! A model is often best suited than a long speech !
On Board Software > Modellling > Objectives
November 2014 42 On Board Software Overview for ULg
Modeling: Objectives
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Characteristics of Useful Models:
● Abstract
● Emphasize important aspects while removing irrelevant ones
● Understandable
● Expressed in a form that is readily understood by observers
● Accurate
● Faithfully represents the modeled system
● Predictive
● Can be used to answer questions about the modeled system
● Inexpensive
● Much cheaper to construct and study than the modeled system
On Board Software > Modellling > Characteristics
November 2014 43 On Board Software Overview for ULg
Modeling: Characteristics
To be useful, engineering models must satisfy all of these characteristics!
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● In an attempt to formalize more and more the expression of the software documentation and production, the design, architecture and requirements have moved from simple text to drawings and from drawings to models.
With the emergence of new tools these model representations can be constructed,
translated and exploited in different ways:
● Analysis: various types of model checking e.g. completeness and consistency analysis
● Simulation: execution of model, behavior can be simulated
● Design: decomposition of system in smaller components, establishing interfaces
● Coding: automatic generation of source code e.g. C or Ada (auto-coding)
● Testing: automatic generation of tests (auto-testing)
● Proving: formal verification or proof
On Board Software > Modeling > Usage
November 2014 44 On Board Software Overview for ULg
Modeling: Usage
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Modeling Methods
● UML (Unified Modelling Language) Not a method (weak semantic) but a notation (well defined syntax) Can be extended by profiles (e.g. SysML, MARTE, …) Can be complemented/supplemented (e.g. OCL)
● AADL (Architecture Analysis and Design Language)
● SDL (Specification and Description Language)
● …. and many others (e.g. AAML …)
● See also Matlab/Simulink/Stateflow
On Board Software > Development > Methods
November 2014 45 On Board Software Overview for ULg
Modeling: Methods
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Use Case Diagram
November 2014 On Board Software Overview for ULg 46
CFDP manager
Communication system
send and receive PDUs
to and from remote
CFDP entities
PUS services
configure, control and
monitor CFDP
transactions
perform high-level
operations on the
distributed CFDP
file-system
transfer PUS
messages to a
remote SC
onboard applicationonboard application
local CFDP entitylocal CFDP entity
local file systemlocal file system
remote CFDP entityremote CFDP entityremote file system
space linkspace link
inter spacecraft linkinter spacecraft link
local CFDP entitylocal CFDP entity
On Board Software > Modeling > UML > Use Case Diagram
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Collaboration Diagram
November 2014 On Board Software Overview for ULg 47
CFDP_ENTITYCFDP_PUS
CFDP_IF_U2E
def ine/delet e/ get conf ig
at t ach def ault conf igs
send asynch nak/ prompt nak/ prompt keep alive
set link availability
updat e rout ing table
def ine/delet e/ get conf ig
at t ach def ault conf igs
send asynch nak/ prompt nak/ prompt keep alive
set link availability
updat e rout ing table
suspend/resume/ cancel/ repor t
put
updat e t ransact ion priorit y
updat e t ransact ion priorit y
PLATFORM
handle PUS TC
handle received PDU
handle t imers
send one PDU
send indicat ions
def ine sender /receiver link def ine remot e ent it y
t ransmit PDU
CFDP_IF_PUSsend PUS TM
CFDP_USER
high level copy
low- level put
suspend/resume/ cancel/ repor t
handle TLV/ put
suspend/resume/ cancel/ repor t
high level f ilest ore operat ion
handle messages to user
CFDP_IF_U2CLIENT
handle request complet ion
handle primit ive indicat ion
handle directory list ing f ilename
generat e TC complet ion repor t
generat e TM primit ive indicat ion
generat e TM dir list ing
generat e TM conf ig report
t rigger failuret rigger failure
CFDP_IF_E2U
primit ive indicat ion (12 t ypes)
handle conf ig report
handle TLV / pr imit ive indicat ion (12 types)
handle conf ig report
t rigger failuret rigger failure
CFDP_IF_FS
open/ close
read/ wr ite
f ilestore operat ions
get t emp f ilename
On Board Software > Modeling > UML > Collaboration Diagram
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Class Diagram
November 2014 On Board Software Overview for ULg 48
cfdp_transaction
cfdp_receiver
0,1
cfdp_sender
0,1
CF DP_ENTITY
1 «Singleton»
*
**
cfdp_remote_ent ity
1. .*
11
cfdp_sender_link
*0,1
cfdp_receiver_conf ig1
cfdp_sender_conf ig1
cfdp_receiver_link
* 0,1
cfdp_receiver_conf ig1. .*
cfdp_sender_conf ig1. .*
cfdp_receiver_conf ig
1
cfdp_sender_conf ig
1
CFDP_PUS
1 «Singleton»
CFDP_USER
1 «Singleton»
CFDP_IF_U2E
1 «platform,Singleton»
«Usage»
CFDP_IF_E2U
1 «platform,Singleton»
«Usage»
CFDP_ENT IT Y
1 «Singleton»
cfdp_pus_request
*
«Usage»
CFDP_IF_U2CLIENT
1 «platform,Singleton»
«Usage»
CFDP_IF_PUS
1 «platform,Singleton»
«Usage»
CFDP_STORE_PUS
1 «platform,Singleton»
On Board Software > Modeling > UML > Class Diagram
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Sequence Diagram
November 2014 On Board Software Overview for ULg 49
CFDP_ENTIT
Y
try to associate the
received PDU with one
of the exist ing
transact ions
platf orm
handle PDU
cf dp_transac
tion
cf dp_receive
r
CFDP_STOR
E_ENTITY
Create
create_new_bit_array
not enough resources
Destroy
Destroy
create_new_transaction
create_new_receiver
delete transact ion
delete receiver
Create
CFDP_IF
_E2U
trigger f ailure
In this example, there is still
enough memory resources f or
cf dp_transaction and
cf dp_receiver but not f or the bit
array.
On Board Software > Modeling > UML > Sequence Diagram
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
State Diagram
November 2014 On Board Software Overview for ULg 50
non available
not lockedlocked
buffer ready
link available
not locked
set to unavailable
set to available
locked
start transfer
buffer ready
set to available
set to unavailable
stopped
started
suspendedrunning
start
suspend
resume
start
f ired
delay elapsedstart
stop
On Board Software > Modeling > UML > State Diagram
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: On Board Procedures
● OBOPs: On Board Operation Procedures
● Quite Simple
● Can be considered as Ground Procedures uploaded on board
● Limited interactions with FSW, through TC and TM
● OBAPs: On Board Application Procedures
● More Complex
● Must be considered as Flight Software
● Tight Interaction with FSW
November 2014 On Board Software Overview for ULg 51
OBCPs: On Board Control Procedures
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
OBSW: On Board Procedures
November 2014 On Board Software Overview for ULg 52
•Target Language •Interpreted •Pre-compiled •Compiled
•Source Language •Instruction Set •Language Constructs
•Production Chain •Preparation Environment •Execution Environment •Management Environment
•Fault Containment
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
Execution Environment
On Board
Debugging Environment
On Ground
Production Environment
On Ground
OBCP
Editor
Production
Program
OBCP
Compiler
Configuration
Data Base
OBCP
Syntax
Data
Handling
Software
OBC
Simulateur
OBCP
Manager
OBCP
Interpreter
OBCP
User
OBCP
Debugger
DHS
Stubs
Validated
OBCP
OBSW : On Board Procedures
November 2014 On Board Software Overview for ULg 53
Copyright
© 2
014 b
y S
PACEBEL –
All
rights
rese
rved
● Functionality: Improved on board autonomy, file based operations, on board data processing, formation flying technologies,
● Distribution, Multiprocessor, Multicore Time and Space Partitionning, Integrated Modular Avionics,
● Standard Architecture Reference Architecture, Application Framework, Middleware, Building Blocks
● Standard Components
Packet Utilisation Standard (PUS), Spacecraft On Board Interface Services (SOIS), On Board Control Procedures (OBCP),
● Methods and Tools:
Component Based Software Engineering, Model Driven Engineering, Requirement Engineering, Automatic Code Generation and Testing, Formal Verification
November 2014 54 On Board Software Overview for ULg
OBSW: Trends