Search Results

To cope with the increasing number of advanced features (e.g., smart-phone integration and side-blind zone alert.) being deployed in vehicles, automotive manufacturers are designing flexible hardware architectures which can accommodate increasing feature content with as fewer as possible hardware changes so as to keep future costs down. In this paper, we propose a formal and quantitative definition of flexibility, a related methodology and a tool flow aimed at maximizing the flexibility of an automotive hardware architecture with respect to the features that are of greater importance to the designer. We define flexibility as the ability of an architecture to accommodate future changes in features with no changes in hardware (no addition/replacement of processors, buses, or memories). We utilize an optimization framework based on mixed integer linear programming (MILP) which computes the flexibility of the architecture while guaranteeing performance and safety requirements.

Current development processes for automotive Electronic Control System (ECS) architectures have certain limitations in evaluating and comparing different architecture design alternatives. The limitations entail the lack of systematic and quantitative exploration and evaluation approaches that enable objective comparison of architectures in the early phases of the design cycle. In addition, architecture design is a multi-stage process, and entails several stakeholders who typically use their own metrics to evaluate different architecture design alternatives. Hence, there is no comprehensive view of which metrics should be used, and how they should be defined. Finally, there are often conflicting forces pulling the architecture design toward short-term objectives such as immediate cost savings versus more flexible, scalable or reliable solutions. In this paper, we propose the usage of a set of metrics for comparing ECS architecture alternatives.

Future automobiles are required to support an increasing number of complex, distributed functions such as active safety and X-by-wire. Because of safety concerns and the need to deliver correct designs in a short time, system properties should be verified in advance on function models, by simulation or model checking. To ensure that the properties still hold for the final deployed system, the implementation of the models into tasks and communication messages should preserve properties of the model, or in general, its semantics. FlexRay offers the possibility of deterministic communication and can be used to define distributed implementations that are provably equivalent to synchronous reactive models like those created from Simulink. However, the low level communication layers and the FlexRay schedule must be carefully designed to ensure the preservation of communication flows and functional outputs.