An embodiment relates generally to testing in-vehicle distributed embedded systems.
In automobiles, several vehicle feature functions are handled by electronics and control software applications. Such systems are distributed real-time embedded software systems that require high integrity development and verification processes. Ensuring consistency and correctness of models across the various design steps is critical in development methodologies. Automotive software is typically created as an initial abstract model of a controller which is then validated using physical testing or formal verification and is refined iteratively. Test sequences created to test the software are a series of commands or instructions that are applied to a device, subsystem or system under test. Physical testing typically requires the setup of a test bed or physical components in an actual vehicle using the actual architecture required for testing or validation. Moreover manual inspection, monitoring, and changes to the physical devices or software are labor intensive, time consuming, and costly.
An advantage of an embodiment is the automated test-case generation for testing end-to-end implementation for a vehicle feature including one or more electronic control units utilizing embedded software under real-time requirements.
An embodiment contemplates an automatic test-case generation system for in-vehicle distributed embedded systems. The automatic test-case generation system generates test-cases for validating a test specification for timing constraints, fault tolerances, distributed deadlocks and synchronization at a system integration level of the distributed system. The automatic test-case generation system includes a model transformer for integrating a functional model and a platform specification. The functional model relates to an abstract model of at least one controller. The platform specification corresponds to a distributed architecture of the in-vehicle distributed embedded system and a mapping of software components to the distributed architecture. A test specification transformer integrates the platform specification, real-time requirements and structural coverage criteria for generating an enhanced test specification for testing the in-vehicle distributed embedded system. A requirements transformer integrates real-time requirements and functional requirements of the in-vehicle distributed embedded system. An automatic test-case generator generates a set of test-cases that validate the enhanced test specification of the in-vehicle distributed embedded system. The test-cases are generated as a function of the outputs of the model transformer, the test specification transformer, and the requirements transformer.
An embodiment contemplates a method for generating automatic test-cases for in-vehicle distributed embedded systems. The automatic test-cases being generated for validating a test specification for timing constraints, fault tolerances, distributed deadlocks, and synchronization at a system integration level of the distributed system. The method includes integrating a functional model relating to an abstract model of at least one controller with a platform specification. The platform specification corresponds to a distributed architecture of the in-vehicle distributed embedded system and a mapping of software components to the distributed architecture. The platform specification, real-time requirements, and structural coverage criteria are integrated for generating an enhanced test specification for testing the in-vehicle distributed embedded system. The real-time requirements and functional requirements are integrated for the in-vehicle distributed embedded system. A set of test-cases are automatically generated that validate the enhanced test specifications of the in-vehicle distributed embedded system. The test-cases are generated as a function of outputs of the model transformer, test specification transformer, and requirements transformer.
There is shown generally in
The automated test generation module 12 includes a plurality of transformer modules for integrating two or more inputs. The plurality of transformer modules includes a model transformer 24, a test specification transformer 26, and a requirements transformer 28. Each of the respective transformers processes the inputs and produces outputs that are provided to an automatic test generator 30. The respective outputs from the transformers include an integrated functional and platform model 32, an enhanced test specification 34, and integrated functional and timing requirements 36. The automated test generator 30 outputs integrated-system test-cases 40 and individual controller test-cases 42. The test-cases may be executed using a harness that can trigger the inputs in any of the components of the systems for which the model is supplied.
The functional model 14 is created as an initial abstraction using a modeling language, such as Simulink/Stateflow (SL/SF).
The model as shown in
The platform specification 16 refers to the distributed architecture in addition to the mapping of software components within the distributed architecture. The distributed architecture includes task scheduling policy of the controllers (e.g., preemptive, non-preemptive), network topology (e.g., interconnections among the controllers by communication buses), characteristics of the buses (e.g., baud rate, protocols such as CAN or FlexRay), data access, fault management, real-time data acquisition, and security.
The task scheduling determines the execution order of the tasks. Each task is selected and executed in a respective order according to the scheduling policy. For example, in preemptive scheduling, a scheduler is allowed to stop an execution of a task before the task has completed its execution, in order to execute another task. The interrupting task may have a greater importance or priority in the task scheduling policy. When the interrupting task has completed its execution, the preempted task resumes its execution. In non-preemptive task scheduling, the task that is currently being executed is allowed to complete its execution regardless of the importance or priority of other tasks.
Feature deployment includes the mapping of components/functions to tasks which implement the functionality; the mapping of tasks to controllers on which the tasks will be scheduled; the mapping of signals to messages (e.g., data transfer between components); and the mapping of messages to buses which carry the messages.
The structural coverage criteria 18 define a set of rules that guides test-case generation, based on coverage of model structure. Various structural coverage criteria defined over model elements include, but are not limited to, condition coverage, decision coverage, Modified Condition/Decision Coverage (MC/DC), state coverage, and transition coverage.
Real-time requirements 20 are the timing requirements for tasks, messages, and other aspects of the distributed system under test. Tasks and messages require verification to ensure that each task and message is meeting its respective deadline. The deadline indicates a time interval in which a respective task or message should be executed. For a task or message requirement, deadlines are verified using offsets, periods, and worst-case execution times (WCET) as illustrated in
Functional requirements 22 are conditions/criteria that determine the correct functioning of the controller software. An example of a functional requirement in the case of the ACC is as follows: “whenever a leading vehicle slows down, ACC shall apply the brake.”
The model transformer 24 receives the functional model 14 and the platform specification 16, and outputs a modified model 32 that incorporates the platform specification. The platform specification 16 provides details of buses, task schedulers, and middleware components for integrating with the functional model 14. An objective of the model transformer 24 is to transform the functional SL/SF model so that timing effects due to the implementation of the controller on a distributed platform are incorporated.
The test specification transformer 26 receives the platform specification 16, the structural coverage criteria 18 and the real-time requirements 20, and integrates them accordingly. The real-time requirements 20 and the platform specification 16 provide coverage criteria for message activations, task activations, etc. The test specification transformer 26 produces an enhanced test specification for testing the distributed system. In addition to the model structural coverage criteria (e.g., state coverage, transition coverage, MC/DC), additional coverage criteria will include covering elements of the platform specification such as triggering of particular tasks and generation of particular messages by tasks.
The inputs to the requirements transformer 28 are the functional requirements 22 and the real-time requirements 20. The requirements transformer 28 integrates the real-time requirements and the functional requirements, and provides modified requirements containing both functional and timing constraints for the featured system, subsystem, or component.
The automatic test generator 30 receives the integrated functional and platform model 32, the enhanced test specification 34 and the functional and timing requirements 36, and generates test-cases that satisfy the test specification/requirements. The automatic test generator 30 is preferably based on a model checking method. Alternatively, other approaches for generating test-cases, such as test generators based on random/directed simulation or constraint solving, may be used. Test-cases are generated at the feature level (for testing the integrated system), and/or the subsystem level (for testing individual controllers).
It should be understood that a vehicle feature may include more than one processing unit (i.e., ECU), and each of the processing units, supporting modules, and devices are executed in parallel. Therefore, a test harness can be utilized to automatically trigger the inputs to any of the respective components for testing and validating the distributed system and the associated embedded software, using the generated test-cases. It should also be understood that the system and methods described herein can be applied to any device, subsystem or system that utilizes embedded software.
In step 62, platform specification, structural coverage criteria, and real-time requirements are integrated for generating an enhanced test specification for testing the distributed system.
In step 63, real-time requirements and functional requirements for the distributed system are integrated.
In step 64, a set of test-cases are automatically generated as a function of the outputs of the model transformer, the test specification transformer, and the requirements transformer.
While certain embodiments of the present invention have been described in detail, those familiar with the art to which this invention relates will recognize various alternative designs and embodiments for practicing the invention as defined by the following claims.