1 / 12

Using Object Orientation in High Integrity Applications: A Case Study

Ada-Europe Conference Vienna, June 20th, 2002. 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. Contents.

marlon
Download Presentation

Using Object Orientation in High Integrity Applications: A Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ada-Europe Conference Vienna, June 20th, 2002 Using Object Orientation in High IntegrityApplications: 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

  2. Contents • Introduction • OBOSS redesign • Analysis of the OO design • Conclusions

  3. 1. Introduction: Goals of the project Is it suitable to use OOP in High Integrity Systems? Is it worthwhile to redesign a system implementationto include OOP features? • 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

  4. 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-basedthe 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. 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. 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. Initialize Start_New_TC_Interpretation Verify_Stage Verify_Step Internal_TC_Source_Data (type) Internal_TC_Representation (type) Parse_TC Example of a Service Provider Device_TC_interpreter Device_Auxiliary_Functions Handle_PUS_Packet TC_Interpreter Device_Command_Parser Command types Parser Interpret_TC (class wide) Parse_Source_Data Generic packages and instantiation

  8. Basic Types Modification • Standard_Value is a type that is the union of allthe 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. 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. 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. 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 providershas 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. 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

More Related