For systems more complex than single ECUs and plant, the ESSE distributed system type of virtual prototypes constructed from operational models of ECUs, plant and networks are more viable technically and economically than HIL and hardware prototypes for both verification and development.

GRAHAM HELLESTRAND
Chief Executive Officer

Home > Solutions > Automotive Systems > Verification > ESSE Virtual Systems Prototypes vs Physical and HIL Prototypes

ESSE Virtual Systems Prototypes vs Physical and HIL Prototypes

Comparison of Multi-ECU Prototyping Capabilities

The table below compares the capabilities of hardware - including HILS - prototyping vs virtual system prototyping. The comparison is for subsystems consisting of multiple plant + ECU + software networked together, and systems consisting of subsystems that are networked together. In both cases the constituent elements are expected to cooperatively work together with the aim of delivering useful and predictable behaviours.

Such subsystems and systems are typically real-time and are subject to the ISO 26262 Functional Safety standard. In this domain mechanisms that efficiently support verification are important.

Architecture & Design

Feature Hardware Prototype ESSE Virtual Systems Prototype
Architectural
Design
Doesn’t support architectural design Supports rapid reconfiguration, empirical investigation and architectural optimization
Prototype Design Requires schematic, layout, and PCB design By product of the architecture process
Manufacture Requires manufacture packaging and testing of ASICs and PCBs N/A - no manufacture
Distribution Physical send via FedEx/UPS/etc. Electronic distribution, instantly to anyone anywhere
Bring-up Each physical prototype "brought up" individually and configured for a dedicated environment including PC and test harness support circuitry Software bring-up occurs automatically in seconds.
Development ready systems are sent to developers
Wiring HIL systems allocate interface pods to pins (not ECUs).
Each ECU may have 100-300 pins - all wiring is manual.
Interconnecting multiple ECUs is difficult and results in an unstable System-Under-Test.
Not a practical engineering solution for multi-ECUs/Subsystems.
Wiring performed automatically as software directive.
No instability due to limit of number of connections practically possible
Execution/Simulation Performance Determined by the hardware prototype design - the components, PCB and the interfaces.
Typically real-time or near real-time performance.
Near real-time performance from 20-200 MIPS
Control Limited ability to do fully synchronous stops and restarts Ability to do synchronous stop and restart. Everything can be forced to stop and start simultaneously
Visibility Visibility limited to the set registers that can be read or scanned. Access to this set is further limited due to timing. Full visibility into the hardware model registers, and accessible variables
Revisions Any hardware changes must go through a similar design, manufacturing, distribution, and bring-up process Revisions are easily made and distributed.
Large projects are easily synchronized via formal revision control systems

Testing and Verification

Feature Hardware Prototype ESSE Virtual Systems Prototype
Repeatability Repeatable testing is compromised by non-deterministic behaviour of hardware with regard to time Virtual platforms have absolute repeatability
Verify Hardware Low visibility.
Cannot stop all clocks simultaneously
Full visibility of hardware models
Full control of state of all models in simulation
Command and Data Sequencing in Peripherals No indication of command - data sequencing error
Very difficult to debug
Insertion of sequencing and access test.
Detection and notification of such error is standard policy in hardware modelling.
Scenario Testing Scenarios require complete system (vehicle + multiple vehicles) for scenario testing.
Not practical in HIL systems.
ESSE - full support for scenarios
Testing in context of Full Vehicle HIL systems very difficult to insert into a car model ESSE - full support
Verify Software Regression testing + software debuggers Regression testing, software debuggers
Controlled fault injection
Many software sequencing errors are caught by access and command testing and sequencing code in hardware
System Verification The long-tail of the V process Done concurrently with design and development - against abstract prototype.
Very short tail (validation only) in the V process.
Fault injection Very difficult and impossible in most cases Full availability of hardware model enables complete fault injection during testing - even dynamic fault testing and fault injection

Original Table in a paper published by E. Lumpkin and C. Alford in 2010 has been augmented and modified here - see www.embedded-systems.com/design/225701094 and www.embedded-systems.com/design/225701109.

For systems more complex than single ECUs and plant, the ESSE distributed system type of virtual prototypes constructed from operational models of ECUs, plant and networks are more viable technically and economically than HIL and hardware prototypes for both verification and development.

For control systems the interactions between ECUs and subsystems are the most likely sources of error and frequently such systems will have high ASIL levels that then require extensive verification to be performed.  The recognition that many such tests from verification suites can be run concurrently, using several virtual prototypes running on different cores and computers, makes the virtual prototype technology a clear winner over HIL solutions.

DSpace, which has recently launched its own virtual-ECUs, has recognised the superiority of Virtual Prototyping over HIL prototyping - both in capability and cost.  The ESSE Virtual Systems - with its most advanced modelling and simulation technology - extends that advantage to cover multiple intercommunicating ECUs, subsystems and systems (of systems). These are areas where HIL systems are impractical.

 

Continue on Verification: