Search Results

Development pace of new embedded projects often requires usage of model-based design process (MBD). More individuals start using MBD without previous experience with tools and new processes. Matlab/Simulink/Stateflow is a common tool that is used in control applications in automotive and airspace industries. Because of its complexity, the tool has a steep learning curve. Therefore, it is vitally important to set the MBD environment that allows persons to develop real-life projects even without a deep knowledge of the tool. The quality of the product should not be compromised and the development time should not be extended due to the initial lack of knowledge of the tool by the developers. The shifting to MBD leads to changes of roles and responsibilities of algorithm designers and software implementers. This shift is due to ability of creating of efficient production code by code generators.

Data dictionaries in embedded automotive applications are used for storing data elements and definitions supporting functional and software development. A robust model-based development process should be driven by a data dictionary that can interact with tools supporting a model-based environment and provide a linkage between different stages of the development process. A data dictionary could significantly increase automation of the modeling, validation and autocoding stages of the process. Using a data dictionary in model-based development implies additional requirements to the Dictionary compared to the traditional non-model development process. This paper describes the usage of a data dictionary in different stages of the model-based development process. It specifies the set of major requirements for the data dictionary and offers the possible implementation of these requirements based on a data dictionary developed by Delphi.

The complexity of automotive software and the needs for shorter development time and software portability require the development of new approaches and standards for software architectures. The AUTOSAR project is one of the most comprehensive and promising solutions for defining a methodology supporting a function-driven development process. Furthermore, it manifests itself as a standard for expressing compatible software interfaces at the Application Layer. This paper discusses the implementation of AUTOSAR requirements for the component structure, as well as interfaces to the Application Layer in a model-based development environment. The paper outlines the major AUTOSAR requirements for software components, provides examples of their implementation in a Simulink/Stateflow model, and describes the modelbased implementation of an operating system for running AUTOSAR software executables (“runnables”).

Audio playbacks are mechanisms which read data from a storage medium and produce commands and signals which an audio system turns into music. Playbacks are constantly changed to meet market demands, requiring that the control software be updated quickly and efficiently. This paper reviews a 12 month project using the MATLAB/Simulink/Stateflow environment for model-based development, system simulation, autocode generation, and hardware-in-the-loop (HIL) verification for playbacks which read music CDs or MP3 disks. Our team began with a “clean slate” approach to playback architecture, and demonstrated working units running production-ready code. This modular, layered architecture enables rapid development and verification of new playback mechanisms, thereby reducing the time needed to evaluate playback mechanisms and integrate into a complete infotainment system.

Since the end of the 1990s, model-based development processes have increasingly been adopted for the development of automotive embedded control software. One of the main goals of this approach is a reduction of project development time. This reduction is achieved through the use of executable modeling and autocoding. Due to the current constraints for a majority of embedded controllers on microprocessor memory and throughput, efficient production-quality code can not be generated from an executable model with the push of a button. The autocoding process requires manual setting of the software properties for the model's blocks and components by a software professional. Once the code is generated, code verification is needed. Although in many cases autocode generation and verification stages take less time to execute as compared to handcoding techniques, they still require substantial time to perform.

Model-based systems development relies upon the concept of an executable specification. A survey of published literature shows a wide range of definitions for executable specifications [1, 2, 3, 4, 5, 6, 7, 8, 9 and 10]. In this paper, we attempt to codify the essential starting elements for a complete executable specification-based design flow. A complete executable specification that includes a functional model as well as test cases, in addition to a traditional prose document, is needed to transfer requirements from a customer to a supplier, or from a systems engineer to electrical hardware and software engineers. In the complete form demonstrated here, sub-components of a functionally-decomposed system manifest as modular reuse blocks suitable for publication in functional libraries. The overarching definition provided by product architecture and by software architecture must also be harmoniously integrated with design and implementation.