RIU as related to SOIS EDS Glenn Rakow CCSDS SOIS Spring Meeting 2013

RIU Definition Remote Interface Unit is usually a multi- function device that typically gathers data from an array of sensors and controls multiple effectors – Sensor interfaces are typically more than one type and usually dumb, i.e., no processing) – Effector interfaces are usually power control

RIU Diagram ADC X=>Y SM RIU OCB Network I/F Controller

Interfaces and Timing MilBus data bus interface is the typical interface and by definition is a request/response transaction that is scheduled onboard the flight software schedule – This permits the off-loading of the time stamping of the data (if done correctly) in the flight software without having the RIU knowledge of time, e.g., the OBC send command to initiate data collection, waits for the collection to be made and reads it back (2 commands – trigger and read) SpaceWire is a new interface but can be handled the same way using RMAP (command/response with trigger and read commands) – However SpW can also initiate data. This is not advisable but if it is done, the data needs to be time stamped from a global knowledge of time, i.e., Time packet and Tone signal. – Network needs to ensure proper delivery within a bounded window. This will require a QoS such as virtual channels or scheduled time slots, and the assumption that data is not stale at source, i.e, smarts in device to continuously update data and time-stamp. This method has been used for science data processing that is performed in hardware (JWST). Not sure if this has been done with flight software. Not recommended.

Future Interfaces Time-triggered buses – RIU have their own schedule (all nodes do) – Global time is known by all nodes – Software synchronized to bus

RIU Operations Two modes for the RIU to operate – Autonomously gather data – Individual sample – For autonomously mode will still have individual sample mode for test purposes Unit conversion – This may be done at RIU (ASIM) or – Done by OBC

NASA GSFC CFS The Core Flight System (CFS) software has a software task that manages the scheduled MilBus traffic according to the global time kept on the C&DH For tight control loops, i.e., (AOCS/GN&C), the schedule requests the data from the device at a faster rate (typically 10 Hz) The data is received via the MilBus controller and put into dual port memory The software schedule task knows when it arrives and retrieves the data from dual port memory, formats it (CCSDS packets) and publishes it on the software bus. The tasks that are awaiting the data wake up and execute Results (effector commands) are then published, picked up by the software bus and scheduled (according to the global timing that triggers the schedule task) Not sure how this fits into the SOIS stack but it works!

Dumb Devices and 1451 The information needed is best used by transcribing it into the SOIS EDS Necessary software information includes: – Address (this is not in the 1451 EDS but dependent upon the multiplexing design of the RIU, i.e., where the sensor is attached) – Setup and hold time – How long the analog channel has to be active before conversion to digital can be accomplished and how long after conversion initiated can the next analog channel be activated – Count-to-unit conversion – Look-up table or polynomial formula (not be necessary if conversion is done in the RIU). In latter case need to indicate what are the units. – For autonomous case (where RIU gathers all channels), address and timing only needed by OBC for diagnostic modes – Effector commands handled in same fashion as the individual channelized telemetry case