on board software

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


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


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


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


OBSW : Process On Board Software > Process

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

OBSW: Phases


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


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


Supported as far as possible by Formal Methods

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

OBSW : Standards


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


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


verification


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


OBSW Architecture

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

Interfaces & Data Flows


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


Functional Architecture (1/2)

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved



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



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


Static Architecture (1/4)

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved



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



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



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


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


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


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


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


Dynamic Architecture: Schedulability

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

Formal Proof

Dynamic Architecture: Schedulability


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


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)


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


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


…MISSION

Applications


…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


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


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


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


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


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


OBSW Environment: Programming

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

OBSW Environment : Production


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


OBSW Modeling On Board Software > Modeling

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

Modeling : Examples


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


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


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


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


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


Modeling: Methods

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

Use Case Diagram


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


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


handle TLV/ put


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


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


«Usage»

CFDP_ENT IT Y

1 «Singleton»

cfdp_pus_request

*

«Usage»

CFDP_IF_U2CLIENT


«Usage»

CFDP_IF_PUS


«Usage»

CFDP_STORE_PUS


On Board Software > Modeling > UML > Class Diagram

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

Sequence Diagram


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


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


OBCPs: On Board Control Procedures

Copyright

© 2

014 b

y S

PACEBEL –

All

rights

rese

rved

OBSW: On Board Procedures


•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


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


OBSW: Trends

on board software

Documents