Aggregated devices in SOIS and SOIS EDS
In SOIS Command & Data Acquisition services, it has been recently highlighted the need to represent
and access equipment which collects/distributes data from/to multiple devices.
This devices can be classified in two main categories:
 Logical aggregation: data coming from devices physically separated and potentially located
on different sub-networks are merged together by the OBC flight SW and exposed as a single
logical device to the user. The logical device merge could be offered by SOIS DVS.
 Physical aggregation: different devices are physically connected to the sub-network by
means of a data concentrator unit (e.g. Remote Interface Unit or Remote Terminal Unit).
The access to the data concentrator unit is managed by the DAS, where are implemented
the specific protocol to access the data concentrator itself and, potentially, the specific
protocol(s) to access the end-node devices behind the data concentrator.
Although in first instance the 2 categories seem to have many common characteristics, actually the
implementation of the services to access them and the representation of their interfaces in the EDS
is quite different.
Logical aggregation
DVS interface exposed to the user application (or SOIS DDPS) is the composition of data coming from
different devices.
The data exposed to the user application (or SOIS DDPS) may have a different formatting with
respect to the input data or may be the result of their elaboration.
In Figure 1 it is shown an example where device 1 exposes a functional interface composed by the
contribution of the physical devices A, B, and C.
The Internals of DVS for device 1 can be split in DVS layers with the same structure:
 In the lower layer a DVS instance for each physical device implements the 1-to-1 access to
the related DAS and performs the transformations specific to that device (e.g. calibration of
the acquired raw data).
 In the upper layer the DVS instance exposes the functional interface to the user application
and merges/format the data coming from the internal DVS instances.
The DVS EDS section capturing this possible use case, would have multiple subsections.
The top one would describe the functional interface to the user application (or SOIS DDPS) and the
Device Abstraction Control Procedure (DACP 1 in Figure 1) necessary to merge/format the
elementary data of the internal DVS instances.
The other subsections would describe the DVS of each elementary device where the functional
interface is the one exposed by the elementary device and the Device Abstraction Control Procedure
(DACP 1A, 1B, 1C in Figure 1) necessary to perform the transformation from DVS to the related DAS
interface (and vice versa).
In case the DVS maps 1 to 1 with the DAS (i.e. there is no logical aggregation), only the top
subsection of the DVS EDS section would be present and the DACP would map directly to the related
DAS (instead of internal elementary DVS interfaces).
The layering inside DVS is presented for clarity and in support to the EDS description, for efficiency
and performance reasons, it is likely that a flight SW implementation of such a DVS would merge the
layers in a single DACP.
OBC
User
Applications
DVS
Device 1 Value ID & Functional I/F
DACP 1
Device 1A Value ID &
Functional I/F
Device 1B Value ID &
Functional I/F
Device 1C Value ID &
Functional I/F
DACP 1A
DACP 1B
DACP 1C
Device A Value ID &
Raw Data I/F
Device B Value ID &
Raw Data I/F
Device C Value ID &
Raw Data I/F
Device A Access
Protocol
Device B Access
Protocol
Device C Access
Protocol
DAS
Figure 1 – Layering of DVS, logical aggregation
Physical aggregation
Remote Interface/Terminal Unit (see Figure 2) is the bridge between the OBC sub-network and a
group of simple devices, its role is mainly to adapt the communication between the OBC and the
elementary devices and, in some cases, to reduce the processing load on the OBC by controlling
autonomously the acquisitions from these devices.
Elementary devices can be connected to the RIU via point-to-point links (e.g. UARTs) or via a sensor
bus (e.g. CAN Bus, I2C).
Two main categories of RIU can be identified:
 Tunnelling RIU is only in charge to multiplex/demultiplex commands and requests between
OBC and a selected elementary/end-node device.
OBC manages each device separately and it is aware of the protocol to access each
elementary device, while the RIU-specific protocol is reduced to multiplex/demultiplex the
connection between OBC and the selected end-node device.
The RIU is almost transparent to the DAS running on the OBC.
 Smart RIU is in charge to autonomously access and collect data from the end-node devices
following a predefined or programmable sequence, formats the data in a single
packet/frame and finally delivers it to the OBC periodically or upon request.
The OBC is not explicitly aware of the protocols necessary to access the elementary devices
and sees the RIU as a single device to be managed.
The communication across the sub-network between OBC and RIU follows SOIS sub-network
services (mainly MAS, PS, SS and possibly DDS), while the implementation of the protocol to access
the RIU internals or the elementary devices are located in the DAS layer.
Device
Device
NCAP
(C&DH)
STI
(RIU)
Device
Figure 2 – RIU block diagram
From the point of view of the services implemented in the OBC, the tunnelling RIU requires a DAS
instance for each elementary device to be accessed. The multiplex/demultiplex protocol can be
embedded in the DAP of each DAS instance together with the end-node device specific protocol (see
also Figure 3).
OBC
RIU
DAS
Device 1
Device 1 Value ID to
Access Protocol
Mapping
Device 2 Value ID to
Access Protocol
Mapping
Device 1 Access
Protocol
Device 2 Access
Protocol
RIU Mux/Demux
Protocol
RIU Mux/Demux
Protocol
Subnetwork Service
Device 2
Device 1 Access Protocol
Device 2 Access Protocol
RIU Mux/Demux
Protocol
Subnetwork Service
Figure 3 – Layering of DAS, tunnelling RIU
The EDS representation reflects the DAS structure and the RIU multiplex/demultiplex protocol can
be incorporated in the DAP description of the specific end-note device.
If a new device is added to the RIU internal bus, a new EDS is introduced describing the interface and
protocol of the new device, a new DAS instance is also needed on the OBC to access the new device.
The services implemented in the OBC to access the smart RIU manage only the RIU and its protocol.
There is a single DAS, where the DAP implements the RIU-specific protocol to command and acquire
data to/from it.
The protocols to access the elementary devices connected to the RIU are not visible to the DAS of
the OBC.
The RIU is supposed to have its own EDS to be used to generate the equivalent DAS, the EDS of the
end-node devices are needed to design the RIU and the RIU EDS, but are not an input for the
definition of the DAS running on the OBC.
In this case, if a new device is added to the RIU internal bus, the configuration of the RIU is updated
and the content of the user’s data transferred between OBC and RIU may change, however there are
no changes in the access protocol implemented in the DAS.
Depending on the user application needs, the aggregated data produced by the RIU and acquired by
DAS could be processed and presented as a single element at DVS functional interface, or split in as
many elements as the elementary devices of the RIU.