Case study: eSOL and Solid Sands

Virtually all of today’s safety-critical embedded software applications are made up of three components: developer-written application code, standard library components and a real-time operating system (RTOS). For Rolland Dudemaine, VP of engineering at eSOL Europe, that last element is why compliance with safety standards, such as ISO 26262 for automotive, is so important. One of his responsibilities is to ensure that the real-time operating system releases that his team develops and supports are exhaustively tested for robustness and compliance.

That is why eSOL chose the Solid Sands SuperTest test and validation suite for C and C++ compilers and libraries to undertake a crucial part of this job. With multi-core processors for automotive and other safety-critical applications currently sporting tens or hundreds of cores on a single chip, verifying operating system compliance is a critical part of the company’s development effort.

“Multi-core processing is a trend we identified a long time ago. We created an operating system called eMCOS, designed to run on systems with up to 256 cores and sometimes even more, which we currently provide to customers mostly in the automotive market,” says Dudemaine. “We also have a team supporting our Autoware, AUTOSAR Classic Platform and AUTOSAR Adaptive Platform offerings.”

Being able to offer safety-certified operating systems and platforms based on eMCOS or AUTOSAR means eSOL needs to provide a fully tested standard programming API, which is where SuperTest fits in perfectly.

“Everyone expects the operating system to be shipped with the C library, and sometimes the C++ library, so we need to make sure that the functionality of these libraries is fully tested in accordance with the latest functional safety (FuSa) methodology.

“For us, the use of SuperTest is essential, because even though we use the Arm platform and a functional safety qualified commercial Arm compiler with a set of pre-qualified C and C++ libraries, they don’t provide all the pieces we need – for example, things like malloc, parts of the C library and POSIX library that are operating system dependent, and some additional headers that are related to our operating system APIs.

“It’s not that Arm has failed to include these things, it’s because they are operating system dependent, so the Arm toolchain assumes that the operating system or platform vendor will implement the remaining pieces.”

eSOL’s eMCOS development team now runs SuperTest on each new release of eSOL’s operating systems to verify that the many operating system APIs that SuperTest covers are functioning as expected.

“We use SuperTest as a functional test suite, a coverage test suite and a compliance test suite, because customers expect eSOL to provide an operating system that is already fully tested and compliant,” says Dudemaine. “SuperTest also has the advantage that several of its customers and partners are already familiar with it and will often use SuperTest themselves for verifying compliance. The fact that we have pre-tested our operating systems and libraries with SuperTest gives them added confidence.

“The two big values of SuperTest are firstly the test suite’s capability itself, and secondly that its existing tests have already been developed and well documented. The addition of new tests to meet our specific requirements was not really difficult,” adds Dudemaine. “SuperTest and the C++ library does part of it, and we have added other tests that cover specific aspects of our operating systems.”

As far as installation was concerned, getting SuperTest up and running was straightforward. “Our initial installation of SuperTest was painless and the code is clean, which meant we were quickly able to get the tool online. And the support we received via Solid Sands’ Japanese distributor was high quality and reactive,” says Rolland. “We don’t simply see Solid Sands as a supplier, we also see it as a partner, because we recognize that SuperTest will also be used by many of our customers.”