Search Results

When implementing production software for fixed-point engine control units (ECUs) it is important to consider the code optimization and code verification strategies for the embedded algorithms. System and software engineers work together to design algorithms that satisfy the system performance requirements without significant numerical quantization results. Software engineers and suppliers in mass production environments then implement the design on an embedded system with limited memory and execution speed resources. The primary goals after design are to generate optimized code and verify that the implementation matches the original model’s functional behavior. Model-Based Design simplifies fixed-point development by providing tools and workflows that support the complete design, implementation, and verification processes. System engineers performing on-target rapid prototyping for fixed-point ECUs benefit from automated scaling workflows that provide an initial fixed-point design.

When developing production software for fixed-point Engine Control Units (ECUs), it is important to consider the transition from floating-point to fixed-point algorithms. Systems engineers frequently design algorithms in floating-point math, usually double precision. This represents the ideal algorithm behavior without much concern for its final realization in production software and hardware. Software engineers and suppliers in mass production environments, however, are concerned with production realities and often need to convert these algorithms to fixed-point math for their integer-only hardware. A key task is to design scale factors that maximize code efficiency by minimizing the bytes used, while also minimizing quantization effects such that the fixed-point algorithms match the floating-point results within an acceptable numerical margin.

When developing software it is important to consider process, methods, and tools. For safety-critical software, standards such as IEC 61508 are often used to impose additional constraints on the development process and require the production of verification evidence and other artifacts. These constraints and artifacts are needed whether or not the design and code were produced manually or via tool automation. This paper discusses the usage of Production Code Generation for safety-critical software development.

Bringing a new automotive electronic control unit (ECU) to market is a multi-phase process. Generally speaking, the phases are engineering analysis, rapid prototyping, software implementation, test and calibration. A variety of engineering staff and tools are used as the ECU progresses through the development process. However, the use of different tools may require non-value-added steps to translate data and results from one process phase to another. This lack of integration introduces the potential for errors, adds delay and costs to projects, and makes it difficult to trace the behavior of the final product back to the original requirements. Model-Based Design addresses many of the integration problems through use of executable specification models and automatic code generation. However, connecting the design effectively to the prototype vehicle provides additional integration challenges since it requires specialized hardware interfaces and target-specific software device drivers.

Software developed for safety-critical systems needs to be of high integrity. Special precautions and development steps are needed for high-integrity software that are not required for other software, although many would argue that they should be. Examples include language subsets, Verification and Validation (V&V), inspections, requirements traceability, documentation, and structural test coverage. Production code generation supports these activities by providing a complete software engineering development environment using models to specify the software. The models can then be tested and stressed within boundaries of the modeling environment. The tests and results can then be reused and applied to the generated code. This paper describes high-integrity code development techniques and shows how they can be automated and applied at the model level, improving quality while shortening design cycles.

The embedded software development process for electronic engine controls is undergoing rapid changes and advancements. A large number of software process improvement (SPI) initiatives have recently commenced, partly in response to emerging technologies involving code generation [1, 2, 3 and 4] and automated testing [5,6]. The ability to generate and test embedded code using computer automation is certainly a tremendous advancement and worthy of review by SPI teams. However, there are other important software engineering tasks that also need consideration including verification and validation, configuration management, and documentation. Powerful computer automated tools are available for nearly every one of these tasks. This makes it easy for SPI teams to get caught up in the excitement of a tool's individual capabilities, without paying attention to its impact on the process as a whole. A software engineering framework consists of a process with methods and tools.

Software developed for high-integrity systems was often required to be written in Ada. In some industries, this requirement has recently been lifted and C is either being used or strongly considered for some next- generation safety-critical development efforts. The overall objective of this paper is to show that the safety of any language can be enhanced by adhering to time-honored software engineering principles, such as strong typing and structured design. The one distinction is in what a language, such as Ada, supports and what a language, such as C, allows. A number of safe design and code examples are provided showing that if a language allows programs to adhere to certain principles then it is possible to satisfy, or at least address safety-critical guidelines as defined by aerospace industrial standards. This paper also introduces emerging European safe language subsets such as SPARK Ada and MISRA C.