LET
The Logical Execution Time (LET), resulting from a research project at the University of California, Berkeley in 2000 – 2003, has been widely recognized as crucial concept for deterministic timing behavior: The same input at certain instants of time always results in corresponding same output values at corresponding instants of time. Under any circumstance, in any case (assuming that the schedulability analysis is correct for the non-TDL components). This determinism radically improves embedded software quality.
Chrona's Timing Definition Language (TDL) has the Logical Execution Time (LET) at its core. The TDL run-time systems allows an efficient execution of LET behavior with negligible computational and memory overhead. We could corroborate this negligible overhead in a Toyota project in which TDL-LET was applied to Toyota's engine control system. The results convinced Daimler in 2015 to go for TDL-LET in Daimler's next generation electric vehicles which are shipped in 2019/20.
platform-aware SIL
Conventional Software-in-the-Loop (SIL) testing does not consider platform and timing aspects and thus errors and bugs are overlooked at that stage in the development process. Chrona's Validator allows the additional modeling of platform behavior (timers, interrupts, OS services, etc). The Validator applies discrete event simulation to get controller behavior as close as possible to the actual behavior on a specific platform. A functional developer typically starts with a coarse-grained, rudimentary platform model which is incrementally refined. For example, bus communication needs not to be considered at the beginning, but can be added later on.
Chrona's Validator has been applied to large industrial legacy systems for simulating the computational part in closed-loop with continuous-time plant models in MATLAB®/SIMULINK®. For that purpose, the Validator allows co-simulation with other simulation tools based on time synchronization protocols, thus supporting a seamless integration in existing MIL, SIL and PIL test chains.
Today multi-core micro-controllers are widely used in automotive applications due to increased performance requirements. At the same time too many data consistency requirements would cancel such performance gains. But how can the minimal consistency requirements be identified? Today this is mainly done by a design/code review of the software module with respect to its input variables.
The Validator allows the identification of so-called problematic access patterns for the input data which are then enforced in the platform-aware SIL in a dynamic stress test. The results of each module are then checked against the expected test vectors. In case such problematic access patterns create a violation of data consistency, that is, a deviation from the expected test results, the generation of a corresponding consistency requirement is indicated to the developer. This automates the identification of a minimal set of consistency requirements.
