HICDS

1
HICDS
HICDSBasic Software and Service Layer Software
Ferdinando Battini - Laben Maria Livia Esposti -
Laben
2
HICDS
Summary

• Layered Architecture for the HICDS Software
• Basic Software
• Service Layer Software
• RT Kernel selection

3
HICDS Software Approach
The architecture of the HICDS software is aimed
at decoupling application software and the
spacecraft underlying resources (no matter
whether centralized or not). This is the aim of
SOIF a service pool for the application. Service
s should be (the only!) point of access to
spacecraft resources services provide
capabilities
4
Goals of HICDS Software

• Goals to provide applications with
• an hardware-independent interface to a service
  provider
• a delocalization of the resources needed by the
  services

This is achieved by means of a SERVICE LAYER
SOFTWARE (SLSW)
5
HICDS Design Criteria
To get the Goals a layered architecture is
adopted
SLSW hides the real spacecraft resources to
applications, providing it with a sort of
virtual spacecraft" no matter whether physical
resources are centralised or not (spread in
remote units)

A Basic Software deals directly with the specific
hardware and resources on board the spacecraft
6
Basic Software Approach

• Basic Software (BSW) It is the software package
  that collects
• kernel
• initialisation
• self-tests
• drivers pieces of software closely connected
  with the underlying hardware devices
• The above features collapse into the bootstrap
  able to test devices, to initialise them and to
  launch drivers execution within the kernel
  support.

Data Link and Physical Layer
BSW
IODL
Boot
RTK
CTX
RM
MEM
COM BUS
OBT
TMTCSC
BSP
CPU
TIMER
WD
UART
EDAC
HARDWARE
7

• Drivers implement a low level abstraction and are
  hardware dependent.
• Goals it is desirable that
• drivers provide the same interface set to upper
  layers
• each driver allows higher levels to avoid direct
  access to memory or registers.
• Example
• 1. open /dev/ram/unprotected
• 2. open /dev/eeprom
• 3. read /dev/eeprom
• 4. write /dev/ram/unprotected
• But even
• 1. open /dev/MMU
• 2. open /dev/PL_SAR
• 3. read /dev/ PL_SAR
• 4. write /dev/MMU/sar_images

8
Information hiding on resource localization
Drivers shall be devoted to the available
communication link
Link_drivers are good candidates to implement
the last part of SOIF communication stack (data
link layer)
Who is keeping information on the actual resource
localization ?
The SLSW layer handling routers to different link
drivers
9
Service Layer Software Approach
Basic Concept Somewhere in the SLSW, there is a
point where the Application meets the actual
resources provided by that specific spacecraft
Consequences

• the I/F btw Application and SLSW are H/W
  independent

• the lowest layer of the SLSW must be H/W dependent

Need of a convergence layer
10
Thermal control
Payload manager
Power regulation distribution
Attitude orbit control
Ground link management
Mode manager
FDIR
virtual router
CDA Services
Stream Service
File Transfer
Confirmed Datagram
Unconfirmed Datagram
Management Service Everything you need to
manage routers
SLSW the SOIF
Application Layer
Resource Database
Transport Layer
Low Overhead Data Link Interface (LODI)
Network Layer
Network Database
the driver wrappers
Convergence Sub-Layer
Data Link and Physical Layer
BSW
IODL
Boot
RTK
CTX
RM
MEM
COM BUS
OBT
TMTCSC
BSP
CPU
TIMER
WD
UART
EDAC
HARDWARE
11
Advantages
Thermal control
Payload manager
Power regulation distribution
Attitude orbit control
Ground link management
Mode manager
FDIR
virtual router
CDA Service
File Transfer
Stream Service
Confirmed Message
Unconfirmed Message
Management Service
SLSW the SOIF
Data Link and Physical Layer
Data Link and Physical Layer
BSW
BSW
IODL
RTK
IODL
Boot
Peltier
Peltier
HARDWARE
HARDWARE
12
Service Layer Software Approach
To handle different spacecraft topologies,
concepts of services resource table network
table are adopted
To decouple application software and the
spacecraft underlying resources the concept of
the abstract devices is adopted.
13
SLSW Reference Model
In compliance to SOIF Reference Model, SLSW
provides
CDA Services (SOIF LODI)
Standard interfaces between flight S/W
apllication and flight H/W (e.g. sensors,
actuators)
To exchange messages btw processes even running
on different units across a communication link
Communication Services (SOIF ISO/OSI Stack)

• Unconfirmed datagram services
• Confirmed datagram serices
• Stream services
• File transfer services

14
HICDS SLSW Services
For HICDS and its demonstrator SLSW will provide
CDA Services (and Time distribution) through
devices abstraction
Whereas the following services are foreseen by
the baseline architecture , for future
implementation

• CDA Services
• (SOIF LODI)
• engineering service
• monitor service
• data pooling service

Communication Services (SOIF ISO/OSI Stack)
15
SLSW Abstract Devices
Abstract device any device has a logical
identifier
Processes interacting with H/W resources cope
with writing or reading operations in cells (i.e.
registers, memory locations, memory mapped
peripherals, FIFO,)
Complex resources are seen as a collection or a
complex set of (adressable) cells within a
given Address space
16
SLSW Abstract Devices Related S/W structure
Contiguous registers
Data block
Contiguous memory cells
Software structure for I/O operations
17
RT Kernel Selection
18
Goal

• To select a suitable Real Time Kernel for the
  SPARC LEON
• processor taking into account the following trade
  factors
• Dependability and safety
• Availability of software development tools
• Real time performance and size
• Involved costs and offered technical support
• Functional services
• SOIF compatibility
• Portability
• Maturity

• Constraint
• open source

19
Analysed Candidates
GNAT
Free open source licence no technical support
ORK
RTEMS
Free open source licence Laben experience
20
Conclusion
GNAT/ORK selected
Rationale

• Dependability calls for the Ravenscar profile
  support (owned by ORK)
• ORK is an evolution of RTEMS towards Ravenscar
  profile
• ORK does not provide BSP for LEON (activity to
  be performed by Laben)
• but it is no point to rework again RTEMS to
  clone ORK