1. Using Object Orientation in High Integrity Applications: A Case Study A. Alonso, R. López,* T. Vardanega, J. A. de la Puente Dept. Ingeniería de Sistemas Telemáticos, UPM, Spain *ESTEC, European Space Agency, The Netherlands Ada-Europe Conference Vienna, June 20th, 2002

2. 19/06/2015© DIT/UPM 2dit UPM Contents 1. Introduction 2. OBOSS redesign 3. Analysis of the OO design 4. Conclusions

3. 19/06/2015© DIT/UPM 3dit UPM 1. Introduction: Goals of the project Approach: Take an existing system Redesign it to include OOP Analyse the results Expected gains: Better design Make the code easier to understand Facilitate system extension Is it suitable to use OOP in High Integrity Systems? Is it worthwhile to redesign a system implementation to include OOP features?

4. 19/06/2015© DIT/UPM 4dit UPM Target System: OBOSS PUS: ESA standard that defines a packet-based interface, for the execution of on-board services: Basis for sending Telecommands OBOSS: Software framework to develop PUS-based the on-board Data Handling Control System Goal: To promote reuse Originally developed with Ada 83 Later, it was upgraded according to RAVENSCAR Execution platform: GNAT/ORK/ERC32 ORK: Open Ravenscar Real-Time Kernel

5. 19/06/2015© DIT/UPM 5dit UPM Analysis of OBOSS OBOSS basic operation: The TC is routed to the service provider Parse the packet and convert to the sub-service internal representation Execute the sub-service Handle possible errors Main drawbacks Packets are represented as variant records The sub-service is selected by case statements Packet operations are in different Ada packages Data representation is also based on variant records

6. 19/06/2015© DIT/UPM 6dit UPM 2. OBOSS Redesign Change the types definition Convert variant records into tagged types Use dynamic dispatching to select operations Use class wide programming to interpret packets Change the design make basic type operations primitive improve reuse of code by rearranging packages

7. 19/06/2015© DIT/UPM 7dit UPM Example of a Service Provider Internal_TC_Representation (type) Parse_TC Parser Initialize Handle_PUS_Packet Device_TC_interpreter TC_Interpreter Verify_Stage Device_Auxiliary_Functions Start_New_TC_Interpretation Verify_Step Generic packages and instantiation Internal_TC_Source_Data (type) Device_Command_Parser Command types Interpret_TC (class wide) Parse_Source_Data

8. 19/06/2015© DIT/UPM 8dit UPM Basic Types Modification Standard_Value is a type that is the union of all the supported parameters and structures in PUS It is defined as an abstract null record It is extended for each of the parameters types Proper functions are provided Function selection, through dispatching

9. 19/06/2015© DIT/UPM 9dit UPM Analysis of the OO Design Space: Less space for representing data types Big increment in program size: Compiler can corrected by optimizing code generation Execution time: OO version is slightly faster

10. 19/06/2015© DIT/UPM 10dit UPM Analysis of the OO design (II) Time predictability The use of OO does not preclude this property Visible case statements are replaced by internal mechanisms Dynamic memory Should be avoided in HIS The new OBOSS system uses the heap: »Can be solved using a pool of access objects Primitive detection technique has been used More help from compilers will be welcome

11. 19/06/2015© DIT/UPM 11dit UPM Analysis of the OO design: Cost of retrofitting OOP The cost of the type modifications has been low, after we managed to understand the code and the side effects The redesign of the service providers has been much higher, but affordable. The expected gains were reached However, we think that arguably there is little benefit in retrofitting OOP into OBOSS, because: The system is well designed Addition of sub-services is not frequent The structure of client packages will not significantly improved

12. 19/06/2015© DIT/UPM 12dit UPM Conclusions Results of the experiment: It is feasible to use (with care) OO in HIS Improvements in the system Code more readable System easier to maintain and extend Some gains in type size and performance System behaviour is predictable Drawbacks Size of the executable Use of heap has to be dealt with more care In this case specific system, is not worthwhile to retrofit OOP into non-OOP