Category: Test

Introduction

The RXF can be bought in a version that is certifiable. So that does not mean it is certified. It is certifiable. That means we have done all work that is done in a certification process, like writing down requirements, connecting them with model elements, creating tests, performing tests and caring about MISRA, coverage etc.

What is the RXF?

It is not an RTOS or an RTE or any other Operating System, also not a driver layer that will give you hardware control.
It is just the functionality that the UML offers that is not available in ‘C’ or ‘C++’. Much of that functionality is implemented by using an RTOS. the RXF is than a sort of Abstraction Layer that makes a unified RTOS API.

When you create an active Class in the UML you tell your audience that this class runs in its own thread. (Or Task or even process but that has some additional difficulties see this article.) This class then should have behaviour, described in either a state-machine or an activity diagram, as it is defined in the UML. There is no other “standard” mechanism, you have to build that yourself. (Remember, the UML is a language, nothing more)

When you use timers in your behaviour diagrams ( like tm(xxx) in a state-machine ) then you will have to use something that times. Either a hardware timer or if you use an RTOS you can use the tick time. But either way: there is no standard ‘C’ or ‘C++’ mechanism for that.

The RXF also takes care of sending and receiving asynchronous events that are used in state-charts.

Certified vs Certifiable

It is very difficult to certify a “half-product” like the RXF. You have to predict all possible uses and much of the functionality depends on the rest of the system. So at best it can be made certifiable. That means that all possible work for a certification is already done, many documents are already there. If you have never gone through a certification process, this is an excellent starting point. The use of modelling is more or less recommended by an increasing number of certification institutes ( They tend to be quite conservative and that is OK! ) so using Rhapsody and the RXF is a huge step forward for setting up your own process.

What is there in the RXF-Cert?

• Bill of Material (BOM)
  Contains a directory of all documents and deliveries. With exact version numbers and MD5 hashes. Also describes the RXF-Cert system borders and its influences on software development and code generation.
• RXF-Cert Architectural Model (RCM)
• High Level Requirements and Specification (SPEC)
• Requirement Traceability Table (RTT)
  Showing full coverage of requirements through system specifications down to module specifications / implementation and tests.
• User Manual (UM)
  How to use the RXF in Rhapsody. Includes installation guide and detailed technical descriptions of the RXF-Cert.
• Validation Plan (ValP) and Validation Report (ValR)
  Describes how we validate the RXF-Cert. Documents reviews of requirements, code and documentation. (Four-eye principle)
• Test Documentation: Verification Plan (VerP) and Verification Report (VerR)
  • Test Concept and Test Process Description
  • Acceptance Test Specification and Results
  • System Test Specification and Results
  • Unit Test Specification and Results (Model Based using the TestConductor)
  • MISRA Conformance Report:
    how MISRA compliance is implemented and what is done to certify that violations are handled correctly
  • All Tests are part of the delivery and can be re-executed by the customer.
• Software Safety Plan
  Describes the strategy of safe software development we have followed during development of the RXF-Cert. Explains traceability, document review guidelines and our personal competence.
• Software Safety Manual
  How is the RXF-Cert intended to be used, what are the restrictions and safety application conditions. Also contains a description of all the functions of the RXF that can be directly called by the user.
• Tool Manual (TM)
  Lists all tools used in RXF-Cert development including reason for usage, classification, statements for safety related usage and detailed version information.
• Software Modification Procedure (SMP)
  How modifications and updates of the RXF-Cert are handled.
• Final Delivery Report (FDR)
  Documents final checks that have been performed when delivering the RXF-Cert.

Vacation time

So. That is what the RXF-Cert is really doing. Literally man-years were invested in creating that. As said, it is a great start for someone who needs to certify his software, many of the pitfalls are already covered.

So. It’s August, it’s vacation time. For me, unfortunately, there is no beach or mountains,, I am moving from my old house to my new house. The latter is not finished so I have to stay in a holiday home for about 4 months. So a sort of vacation… Luckily there is internet there so I will keep writing, don’t worry!

Sunny modelling with Rhapsody and the RXF

Walter van der Heiden ( wvdheiden@willert.de )

So I returned to Shanghai after only 10 days at home… Again a long flight but this time I was more lucky… I had obtained a cheap (well cheap… let’s jst say not so expensive) business class flight. Always good to sleep on the flight east. This time my route was different, first from the best to the worst airport in the World (my regular readers know exactly what I mean) and then a direct flight to Shanghai. Not with KLM/Air France but with China Eastern. Is not bad, and the chair was good so I actually slept good. That really helps.

Hotel “near” the airport

My hotel was booked and was allegedly close to the airport. I was picked up by a hotel shuttle. Indeed an old small bus arrived that picked me up and drove for 45 minutes to the hotel. Driver and security guy (??) were smoking heavily and driving like a maniac.
But I survived and arrived at the hotel around 11 in the morning.
That was no problem apparently, I got my room and decided to immediately get some sleep. Well no problem… getting the room and making myself understandable was a problem. Nobody spoke English. Not a single word…. They all used their phones where they spoke something Chinese and then the phone would display the English text. Sounds good but “Basic how you do brush rooms” was not really comprehensible.
Luckily I had somebody in China that I could call (I still had my Chinese SIM card (See: Shanghai AUTOSAR) So after a few phone calls my room was ready. A very weird room, there was a window but very high and that only showed a hallway… But I was tired so I went to sleep for 2 hours.

MagLev

So the hotel was pretty far from the airport. Checking the map showed me that it was pretty far from everything… Shanghai is big. Seriously big… So the shortest and definitively fastest way to go to town was to use the MagLev (Magnetic Levitation) Train from the airport. I could use the hotel shuttle to get there (When it drove…) or a Taxi. (I managed to get WeChat running and Didi, Chinese Uber, so I could easily take a cab.
From the Airport you’d have to walk a bit but between the 2 terminals was the train station where the MagLev would launch….
What is MagLev? Well, it is the German “Magnetschwebebahn” the magnetic glider train. The tracks are supercooled magnets that lift the train and also cause it to move forward. Brilliant concept. Uses a lot of power unfortunately. In Germany a very heavy accident happened on the test track (not far from my home in the Netherlands) and then the project was topped but China has bought the technology.
It is really a pity that the concept is not used more often. The 32 kilometer from the airport to the city took me about 6 minutes. Imagine that Munich… traveling to the city in less than 10 minutes instead of sitting in a crappy S-Bahn for over an hour….
The train travels with a top speed of 430 km/h. Unfortunately they did not always reach that speed, most of the time they limit that (due to power reasons I think) to 330 km/h. Still breathtakingly fast but not 430.

Testing

In Shanghai I visited the office of my friends at BTC, from test Conductor, and also the MagLev made me think about testing.
Of course driving around with 430 km/h requires a lot of safety relateed software which also requires a lot of testing.
For those who use Rhapsody but have never heard of TestConductor: shame on you! Test Conductor is a fantastic add-on to Rhapsody that helps you to setup your testing inside of Rhapsody. It uses Sequence Diagrams to create test-cases (But you can also create your own using code, Sequence Diagrams aor Flow-charts) and to run the tests.
You can automatically create test-architecture, create tests and run them. The tests, the results and more is stored in your Rhapsody Model includeing references to the tested elements.

TestConductor can cooperate with the Willert Target Debugger to let your tests run on your target! It can also create coverage reports, for model, code and requirements!
It is really very easy to use, you will find a thorough manual and a very well structured getting Started in your Rhapsody Directory “Samples” (Next to the Share directory) Check under Csamples and CppSamples to find the TestConductor directory. In there is the “Testing Cookbook” which tells you exactly how it works!

Interested? Ask me for a test license

That’s it, have fun testing with Rhapsody!

Walter van der Heiden ( wvdheiden@willert.de )