Overview of Existing Safeguarding Techniques
for Automatically Generated Code
Ingo Stürmer
Member of the ACMDaniela Weinberg
Fraunhofer FIRST Computer Architecture andSoftware Technology
Mirko Conrad
DaimlerChrysler AG Research and TechnologyREI/SM
ABSTRACT
Code generators are increasingly used in an industrial context to translate graphical models into executable code. Since the code is often deployed in safety-related environments, the quality of the code generators is of paramount importance. In this paper, we will present and discuss state-of-the-art techniques for safeguarding automatic code generation applied in model-based development.
Categories and Subject Descriptors
D.2 [Software Engineering]: Software/Program Verification, Testing and Debugging
General Terms
Design, Reliability, Human Factors, Standardization, Languages, Verification.
Keywords
Model-based development, automatic code generation, testing, modelling guidelines
1. INTRODUCTION
In the automotive sector, the way embedded software is de-veloped has changed. Executable, graphical models are used at all stages of development – from specification to implementation as well as for testing (model-based development). Such models are designed with popular graphical modelling languages such as Matlab/Simulink and Matlab/Stateflow from The MathWorks. In the past, these models were implemented manually by program-mers. Recent approaches allow the automatic generation of effi-cient controller code directly from the software model via so-called code generators (model-based code generation). Code gen-erators, such as TargetLink [4] or the Real-Time Workshop [5], are examples of software tools upon which software designers rely since the code generated is often deployed in safety-related environments (e.g. brake systems). Furthermore, the adoption of reliable tools such as code generators is a crucial factor for com-petitive embedded software development. However, at present, code generators are not as mature as C or ADA compilers which have been proven reliable in use; thus, their output must be checked with almost the same, expensive effort as is needed for
manually written code. For that reason, code generators must be safeguarded as part of the model-based development tool-chain to such an extent that errors possibly incorporated by inappropriate modelling or by the code generator itself can be detected and avoided as far as possible.
In this paper, we will give an overview of existing safeguard-ing techniques for automatically generated code. The term “safe-guarding” refers to techniques and procedures which are applied in practice to increase confidence in the generated code as well as to those techniques which ensure that the code generator works as expected. In that context we will discuss which one of the respec-tive development artefacts (i.e. model, generated code) and tools (code generator, compiler, etc.) can be safeguarded. For that pur-pose, we will first observe safeguarding techniques for the code generator itself. We will then discuss certain requirements that the model should comply with since models are the central part of the whole model-based development process. These models not only serve as a basis for software design and implementation but also for testing. Furthermore, they are designed by humans and are the input for the code generator. It is worthwhile to note that the qual-ity of the code generated is closely connected with the qualqual-ity of the model. Finally, we will focus on the code generated and dis-cuss how it can be safeguarded during the development process.
2. MODEL-BASED CODE GENERATION
In model-based development, the seamless use of executable models is characteristic for function and control system design and the following implementation phase. This means that models are used to represent the development of the system from the preliminary to the detailed design. At the beginning of this model
evolution there is usually a so-called physical model, which is
derived from the functional specification of the software compo-nent to be realised (ref. Figure 1). The physical model contains the control function to be developed and describes the behaviour of the control function related to a given (continuous) input signal as well as internal or external events or states. The purpose of the physical model is to depict the algorithms to be developed “in their purest form” without already having to pay attention to re-alization details. The description of the algorithms thus takes place through the use of floating-point arithmetic. Since this model can already be executed in a simulation environment on the development computer (host PC), it is also called an executable
specification.
For reasons of efficiency and because of the fact that the real input and output in the physical model is abstracted where neces-sary, the physical model cannot serve directly as a basis for deriv-ing production code for the target processor. It is therefore revised from a realization point of view (for example function parts are distributed to different tasks) and enhanced with the necessary © ACM, (2005) This is the author’s version of the work. It is posted
here by permission of the ACM for your personal use. Not for redis-tribution. The definitive version was published in ACM 1-59593-128-7/05/0005. http://doi.acm.org/10.1145/1083190.1083192
implementation details. In order to do this, the floating-point arithmetic contained in the physical model is adjusted to the arithmetic of the target processor (for example 16-bit fixed-point). This means in particular, that only fixed-point data types are used (e.g. int16), which are provided with scaling information in order to keep imprecision in the presentation of fixed-point numbers as low as possible. The result of this adaptation is an implementation
model which contains all the information necessary for code
gen-eration and makes the creation of efficient C-code possible. The principle of automatic code generation presented in Fig-ure 1 also shows the tools involved in the model-to-code transla-tion process. Depending on the purpose, the code is generated on a host PC (development environment) whereas a classical com-piler/linker combination is used for the translation of the gener-ated code. For an embedded processor (experimental hardware or electronic control unit (ECU) ) a so-called cross-compiler is re-quired with a linker and a loader which allows to bring the ma-chine code onto the embedded device.
The sources of errors, which can be identified within this devel-opment tool-chain, are (1) design errors which are caused due to inappropriate design of the (physical) model with respect to the functional requirements or due to misunderstandings regarding the semantics of the modelling language; (2) arithmetic errors due to imprecise representation of the control function’s arithme-tic within the implementation model or due to improper floating-point to fixed-floating-point conversion (e.g. quantization errors); (3) tool
errors incorporated by a tool within the tool-chain that contains
implementation bugs or that has not been set up correctly (e.g. code generator configuration); (4) hardware errors of the devel-opment or target environment itself; (5) run-time errors caused on the target hardware due to e.g. resource demand mismatches, scheduling etc.; and (6) interface errors between the generated control algorithm, legacy code (e.g. custom code) or wrapper software (driver, operating system etc.).
Implementation Model (fixed-point) C Code Code generator Compiler (Linker) Host PC Target Physical Model (floating-point) Cross-compiler (Linker / Loader) Figure 1: Principle of Automatic Code Generation
In the following, we will present safeguarding techniques which are applied in practice in order to reveal possible errors within the code generation tool-chain.
3. SAFEGUARDING THE CODE
GEN-ERATOR
Usually, the tools that are most likely to be correct are those which have been well designed and written, and which, above all, have been developed with correctness in mind [6]. In the context of model-based development, those techniques and procedures
which are applied in practice to increase confidence in the code are the most relevant ones. They can generally be divided into
constructive procedures (e.g. adoption of standards and
guide-lines) and analytical procedures (e.g. verification and testing). In the following, we will provide an overview of common construc-tive and analytical procedures.
3.1 Adoption of Standards and Guidelines
Constructive procedures guarantee that the tool has been de-veloped according to a systematic development process. Such a process is often defined in accepted standards or guidelines. This also includes the certification, or, more precisely, the qualification of the code generator. For that purpose, the tool supplier should develop his tool within an established Quality Management Sys-tem (QMS), which should preferably be externally certified to a recognised standard (e.g. ISO 9001 with the TickIT Guidelines).3.1.1 SPiCE and CMM
Over the years, a large number of software quality standards have emerged. In the early 1990s, a working group from ISO/IEC was set up to define a common standard based on existing interna-tional and corporate standards. In 1995, a new standard was pub-lished. This standard was mainly influenced by CMM (Capability and Maturity Model), Bootstrap and the ISO 9000 series. The first version of the standard was first published in 1995 and un-derwent trials as part of the European SPiCE (Software Process Improvement and Capability determination) project. CMM, ISO 9001 and ISO/IEC 15504 are process-oriented development stan-dards that provide a framework for managing the increasing com-plexity in software development. The SPICE standard is also highly suitable for developing a code generator cf. [3], [7], [13].
3.1.2 MISRA C
The most important technical standard for any code tor is the standard for its output language [7]. Most code genera-tors produce C code, which is standardised internationally by ISO/IEC 9899 (identical to ANSI X3.159). However, there are several supplementary standards and publications. In this paper we will focus on the MISRA-C Standard, which has gained much acceptance in the automotive industry so far. Since 1998, a com-monly accepted standard called "Guidelines for the Use of the C Language in Vehicle-Based Software" (MISRA-C:1998) has ex-isted, which was developed by the British Motor Industry Soft-ware Reliability Association (MISRA) and defines 127 coding rules. The rules aim at avoiding common (human) programming errors. For this reason, complying with all the rules does not nec-essarily have a positive impact on automatically generated code. However, there is actually no code generator which is capable to generate efficient code which also conforms to the MISRA rules (examples for acceptable rule violations due to efficiency prob-lems are presented in [7]). It is worth it to note that that the MISRA consortium has not faced this dilemma within the newly revised MISRA-C:2004 standard.
3.2 Tool Certification (Qualification)
Certification can be defined as a third party assessment made
by an official and independent organization. It is a way to protect a tool supplier as well as the customer: the customer can be sure that the product satisfies commonly admitted characteristics. The supplier gets an independent approval that techniques, applied for developing and verifying the product, are in compliance with the safety requirements for the specific criticality level. Certified code generators would permit to certify safety-critical software on
the model level, which promises to be less time-consuming, cheaper, and more reliable then the current practice to inspect the source code and/or generated machine code. There are two widely accepted software (system) certification standards: the avionics process standard DO-178B and the international safety standard IEC 61508. Both are discussed with respect to code generator certification in the following:
3.2.1 DO-178B
Avionic standards such as DO-178B encourage the
qualifica-tion of code generaqualifica-tion tools. Qualifiable code generators, such as
SCADE, which endorse a certification of the application software, do exist. However, they only make it possible to reduce the amount of some of the verification activities but do not allow them all to be omitted completely. In addition, their source lan-guage is not as popular as Simulink / Stateflow and they perform only a limited amount of optimisations. The qualification of a development tool can be treated similarly to the certification of the application software itself. Thus, qualifying a development tool such as a code generator does not mean proving its correct-ness. Instead, it is important to gain sufficient confidence in its correctness [6].
3.2.2 IEC 61508
IEC 61508 is an international safety standard which can be adopted for certifying safety-related (software-based) system parts. Certification is not explicitly formulated within the scope of IEC 61508. However, in the terms of IEC 61508, software must be assessed by an independent certification body with respect to the aspired Safety Integrity Level (SIL) of the (software-based) system. In the case of IEC 61508 the TÜV (Germany) and Fac-tory Mutual (US) are generally accepted as suitable certification bodies. In the context of IEC 61508, to date, only compilers (translators) are regularly subjects to tool certification procedures. Compiler (or translator) assessment is possible in two different ways: (1) the compilers or translators are certified against their respective language or process standards (2) Compilers or transla-tors are assessed by their increased confidence from use (i.e. cor-rect performance demonstrated in many projects).
Following the certification practice of the TÜV it is also pos-sible to certify a code generator by establishing its “Fitness for Purpose”. This procedure proposes that an assessment should be carried out in order to ensure that the tool is fit for its intended purpose (However, in the IEC 61508 guidelines it is left open how such an assessment is to be performed). ASCET-SD, developed by ETAS, is the first code generator for automotive embedded control systems that is certified as being fit for its purpose for SIL 3 according to IEC 61508 [13]. In order to gain this certifi-cate the TÜV inspectors analyzed the ETAS tool-chain inten-sively so to understand the purpose of its use and the tool’s devel-opment process. Based on this knowledge, the inspectors created a test plan according to the IEC 61508 SIL 3. This test plan should access the “Fitness for Purpose” of the code generator and includes, for instance, formal characteristics of the documenta-tion, software requirements specificadocumenta-tion, the test as part of de-sign, development and integration, verification and validation (V&V). Following that test plan the tool developer could show, as an example, “the existence of conclusive evidence for correct code generation” [13].
3.3 Testing and Verification
Analytical procedures are methods and techniques which as-sure that (design) errors within the tool have been detected or
avoided as far as possible with methods such as testing or formal verification. Such analytical procedures are also often termed verification and validation (V&V) methods.
3.3.1 Code Generator Testing
Code generators which translate a high-level graphical lan-guage into efficient code constitute a new kind of development tool and, as a result, systematic testing approaches are largely unexplored or unpublished. However, the few published testing procedures for code generators used in practice can be divided up into four categories, which are often adopted consecutively or in combination with each other cf. [3], [7], [11]:
• Test of Core Capability: with the testing of the core capa-bilities, individual Simulink and Stateflow blocks (basic blocks) as well as code patterns which are applied during code generation, are tested rigorously against expected val-ues. These blocks (and patterns) are varied with respect to data types and scaling information and are executed on dif-ferent target processors. Consequently, it is quite common to have a few hundred thousand test cases. The execution and result evaluation is largely automated.
• Test of Core Capability Combinations: combinations of individual blocks and frequently used modelling patterns are tested against expected values. Here, the main focus is often placed on the optimisations performed by the code generator. The determination of expected values as well as test result evaluation is performed manually.
• Large-Scale Usage of Core Functionality: large customer models are used to check the tools for robustness and cor-rectness. The test results are analyzed in detail by experts. • Test of Code Generator Configuration: a (semiautomatic)
system test checks the installation, configuration and opera-tion of the code generator on different PC configuraopera-tions and together with different software versions of the tools in-volved in the tool-chain (e.g. compilers).
A reliable and accepted way to increase confidence in the correct functioning of a translation tool such as a code generator is to validate the code generator by means of a test suite, which is common practice for compiler validation [11]. For this reason, a generic Autocode Validation Suite (AVS) is now under construc-tion, which is capable of thoroughly validating a specific transla-tion functransla-tion (e.g. optimisatransla-tions) applied by a code generator. The theoretical foundations of the test suite have been presented in [1] which also defines a general procedure for testing code generators systematically.
3.3.2 Code Generator Verification
A very strong approach for demonstrating the conformance between implementation and design is to formally prove that the implementation has the same semantics as the design. Several compiler proofs have now been published [9]. However, under realistic conditions, the industrial benefit of the code generator verification approach could not yet be shown: There is currently no formally proven compiler in use which has reached industrial maturity. Nobody has succeeded in producing a correct compiler for a realistic programming language for two main reasons [10]: first, the range and precision limitations on computers were ig-nored; second, the formal methods chosen to describe the source and the target language and the intermediate languages in the compiler made the treatment of realistic programming languages too difficult. As a consequence, attention was restricted to
rela-tively simple programming languages, disregarding the complexi-ties and pitfalls of realistic languages.
4. SAFEGUARDING THE MODEL AND
THE GENERATED CODE
So far, we have taken a closer look at the code generator it-self. Now we will focus on the input provided to the code genera-tor and the output it produces.
4.1 Modelling Guidelines
The quality of the (implementation) model substantially de-termines the quality (correctness, efficiency etc.) of the generated code. Therefore, guidelines and patterns for model design exist, such as those published by the MathWorks Automotive Advisory Board (MAAB Guidelines). Following the modelling conventions stated in such guidelines allows for the translation of the model into safe and efficient code. In order to ensure the efficient man-agement and publishing of such guidelines and pattern collec-tions, specific tool support is necessary, such as presented in [8]. The latter collection describes typical problems and suggests base-patterns that should be used and reused during the develop-ment of functions in order to avoid troubleshooting during or after code-generation. However, the adoption of guidelines and pat-terns for modelling has certain advantages: (1) increase of com-prehensibility (readability), (2) maintainability, (3) reusability and extensibility, and (4) ease of testing.
4.2 Autocode Aspects
In order to assure that the quality of manually-created code is acceptable, it is common to verify and validate the code by using techniques such as reviewing, testing, and static analysis. How-ever, if the code is generated automatically by means of a code generator, any errors will tend to be systematic, because the tool should behave identically for the same model and code generator configuration. [2] compares the V-model for plain, manually gen-erated code using models and automatically gengen-erated code and points out the advantage of model-based code generation. How-ever, in the following we will present safeguarding techniques for automatically generated code.
4.3 Autocode Review
Reviewing manual code is a widely accepted practice used to find errors in the code. In order to do this, the code needs to be well-structured and documented. In contrast to manual code, the code generated automatically will have a low density of faults, if the code generator used works properly. Autocode peer review can be quite effective (even though it is inefficient) since inap-propriate modelling and improper variable scaling, for instance, is easier to detect in the code than in the model.
4.4 Static Analysis
There may be situations in which static analysis tools can help in the process of reviewing the code. Advanced static analy-sis tools, which are available for languages such as C, can extract from code the essence of what it actually does. This may be easier to be compared with the input notation than the actual generated code itself. Such analysis tools check the syntactic correctness and, to varying degrees, the semantic correctness of programming language source code. They add a greater degree of rigour to the kind of checks performed by a compiler. These tools will not check whether the code has the functionality the programmer
intended, but will find constructs which might be erroneous or non-portable, as well as constructs that do not behave as expected.
4.5 (Model-based) Testing
When testing manual code, the main focus is on testing the functionality of the code and ensuring that the code is correct. Testing, thus, does not verify the code against its design. In the case of automatic code generation, however, the model is tested against its requirements and the code can be verified against the executable model by means of dynamic testing. For this purpose, that both the model and the code are executable can be exploited. Both executables are stimulated with the same inputs (cf. Fig-ure 2). Afterwards, the two outputs will be compared with respect to certain acceptance criteria. This comparison yields some tech-nical problems that must be considered. Due to quantization er-rors, the outputs of the model, for instance, and the output of the generated code are usually not identical. As a consequence, so-phisticated signal comparison methods have to be applied.
The question what constitutes appropriate test stimuli for model and code testing is fundamental. The use of structural test-ing criteria on model level (model coverage) and code level (code coverage) for test stimuli determination is meanwhile widespread in practice. Model coverage supplements the known benefits of code coverage, namely controlling the test depth and detecting coverage holes in given test suites. Furthermore, test stimuli gen-eration for model and code coverage can be automated by the use of test vector generators such as Reactis1 for model coverage or the Evolutionary Test Tool [14] for code coverage.
One of the great advantages of model-based development is the opportunity to simulate the model and the generated code at different stages of the development process. Here, different ways of simulation (cf. Figure 2) support the safeguarding of the model and the generated code:
• Model-in-the-Loop (MiL): MiL simulation captures the specified behaviour of the model that is to be implemented in C code later on. This simulation is executed on the host PC. The simulation results are used as a reference (expected val-ues) for the following software verification steps. The aim of MiL is to check the validity of the model with respect to the functional requirements within the development environ-ment. Additionally possible simulation pathways within the model can be measured with model coverage criteria (e.g. decision coverage or MC/DC coverage).
• Software-in-the-Loop (SiL): The implementation model that was used during MiL is now compiled and executed on the host PC with the same stimuli used for MiL. The execu-tion results should be comparable to the results obtained dur-ing MiL. Results can differ, however, due to different han-dling of numerical instabilities or exceptional hanhan-dling of the MATLAB simulation environment and the code executed. The aim of SiL is to analyze fixed-point scaling effects of the generated code, to detect possible arithmetical problems (e.g. over-/underflow), and to measure code coverage.
• Processor-in-the-Loop (PiL): The generated code is (cross-) compiled using the project’s target compiler. After-wards, the code is executed on an experimental hardware, which contains the same processor as the target system (such
as an evaluation board) but contains additional resources for storing and exchanging test data and test results. The aim of PiL is to verify the code behaviour on the target processor and to measure code efficiency (profiling, memory usage, etc.).
• the-Loop (HiL): Finally, during Hardware-in-the-loop simulation, the software embedded into the target ECU is executed. For that purpose, the ECU is connected to a real-time simulation system simulating the plant. Thus, the aim of HiL is to check the software on the ECU with its elec-trical interfaces.
test stimuli
Test model
≈
Code
Test output (Host PC) Test output (Model)
MiL
SiL Code generator
Compare results Test output (Experimental HW)
PiL Test output (ECU)
HiL
Figure 2: Process for Testing Automatically Generated Code
5. CONCLUSIONS
In this paper we have taken a closer look at safeguarding techniques for automatically generated code. A survey of possible safeguarding techniques for automatic code generation is pre-sented in the appendix. As we have seen, the code generator itself should have been developed with correctness in mind and within an established quality management system. Furthermore, the code generator should be validated by an Autocode Validation Suite, which is capable of verifying the code generator’s correct imple-mentation [12]. But how can a code generator work correctly if the input model it is given is not set up well? So, the second im-portant issue is the input model for the code generator. Since there is no published standard for graphical modelling languages avail-able, it is recommended that the developers of such models have a cross-discipline skill set. It would certainly be an advantage if model developers used a commonly accepted and thoroughly tested set of base-(sub)models. This would make models from different developers more alike in appearance and therefore the models would be easier to read and understand for others. Overall, a common set of patterns and guidelines used widely in practice may lead to a national or international standard for such graphical models in the future. The third issue we considered was the gen-erated code. We described practical ways of gaining confidence in the code. These techniques range from manually reviewing the code and having tools analyze the code up to different simulation
modes. These simulation modes are especially relevant in order to verify the model at an early stage in the development process. As we can see from the variety of techniques available, there is not just one way to make the automatically generated code more reli-able. Moreover, it is a matter of how to combine available tech-niques in order to increase confidence in automatic code genera-tion.
Acknowledgement
The work described was partially performed as part of the IMMOS project funded by the German Federal Ministry of Edu-cation and Research (project ref. 01ISC31D). http://www.immos-project.de.
6. REFERENCES
[1] Stürmer, I. and Conrad, M. Test Suite Design for Code Gen-eration Tools. 18th Int. IEEE Conf. on Automated Software Engineering, pp. 286-290, 2003.
[2] Burnard, A. Verifying and Validating Automatically Gener-ated Code, Int. Automotive Conference (IAC), pp. 71-78, 2004.
[3] Beine, M., Otterbach, R. and Jungmann, M. Development of Safety-Critical Software Using Automatic Code Generation,
Society of Automotive Engineers (SAE), 2004-01-0708, 2004
[4] dSPACE. TargetLink 2.0: Production Code Generator.
http://www.dspace.com, 2004.
[5] The MathWorks. RealTimeWorkshop/Embedded Coder,
http://www.mathworks.com, 2004.
[6] Edwards, P.D. The Use of Automatic Code Generation Tools in the Development of Safety-Related Embedded Systems. Vehicle Electronic Systems, European Conference and
Ex-hibition, 9.-10. June, 1999.
[7] Thomsen, T. Integration of International Standards for Pro-duction Code Generation, Society of Automotive Engineers, Doc.-No.: 2003-01-0855, 2003.
[8] Conrad, M., Dörr, H., Fey, I., Pohlheim, H., Stürmer, I. Guidelines und Reviews in der Modell-basierten Entwick-lung von Steuergeräte-Software (in German), 2. Tagung Simulation und Test in der Funktions- und Softwareentwick-lung für die Automobilelektronik, March 14.-15, 2005. [9] Dave, M. A. Compiler Verification: a bibliography, ACM
SIGSOFT Software Engineering Notes, Vol. 28 (6), 2003. [10] Goos, G. and Zimmermann, W. Verifying Compilers and
ASMs, Abstract State Maschines, LNCS, 1912:177-202, Springer, 2000.
[11] Tonndorf, M. Ada Conformity Assessments: A model for Other Programming languages? ACM SIGAda Ada Letters, Vol. XIX (3), pp. 89-99, 1999.
[12] Stürmer, I., Conrad, M. Code Generator Testing in Practise,
2nd Workshop Automotive Software Engineering, 2004.
[13] Junker, F., Glöe, G. Guaranteed Product Safety According to the IEC 61508 Standard, RealTime, Vol. 1, pp. 28-29, 2003. [14] Wegener, J., Stahmer H. and Baresel, A. Evolutionary Test
Environment for Automatic Structural Testing. Special Issue
of Information and Software Technology, Vol. 43,
Appendix: Safeguarding Techniques for Automatically Generated Code
Aspect Safeguarding technique Possible Aims
Functional MiL simulation / testing • Verify that the model (PM, IM) reflects its functional requirements specification
• Check validity of the model within the development environment without resource limitations of target environment
• Verify floating-point to fixed-point conversion (PM IM) Structural MiL testing
(model coverage) • Explore possible simulation pathways within the model by determin-ing test cases on the basis of the model structure Adoption of modelling guidelines • Rely on experiences and expert knowledge
• Use well-known patterns for safe and efficient code generation • Avoid error-prone modelling constructs
Physical model (PM), implementation model (IM)
Model review • Reveal design errors at an early development stage • Ensure that modelling guidelines have been applied Code Generator Adoption of development standards
and guidelines • Ensure that the code generator has been developed following a sys-tematic development process / quality management system Tool certification (qualification) • Independent approval which guarantees that techniques, applied for
developing and verifying the tool, are in compliance with the require-ments of a certification standard
Testing (Autocode Validation Suite) • Ensure that the code generator has been tested rigorously
• Validate that specific translation functions (e.g. optimisations) behave as expected
• Replacement of tool certification by using a certified Autocode Vali-dation Suite
Formal proof
Restriction to a safe subset of the code generator functionality
• Show by means of mathematical proofs that each code generation (rule) preserves the model’s semantics
• Increased confidence by using only 'well known' features
• Restriction of V&V activities to only those features which are relevant Generated Code Functional SiL simulation / testing • Analyze fixed-point scaling effects
• Detect arithmetical errors • Rapid prototyping
Functional PiL simulation / testing • Check validity of code behaviour taking arithmetical constraints and resource limitations of the target processor into account
• Analyze fixed-point scaling effects on target processor • Measure code efficiency
Functional HiL simulation / testing
HiL-Simulation / Testing • Check behaviour of code within the target environment (ECU) with its electrical interfaces Structural MiL / SiL / PiL testing
(code coverage) • Determine test cases on the basis of the code structure • Explore possible execution pathways within the code by determining test cases on the basis of the software structure
Code review • Find errors caused by inappropriate use of the code generator • Reveal implementation errors caused by integration of custom code
parts
• Detect errors within the implementation model (which are hard to find in the model)
• Identify inefficient code parts
Static analysis • Check that code conforms to coding guidelines (ANSI C, MISRA C) • Detect dead code, etc.
