Distributed automotive electrical/electronic system design and implementation architecture

In the past decade or so, the electrical and electronic systems of automobiles have become very complicated. Today's automotive electronics/electrical system development engineers use model-based functional design and simulation to meet this complexity challenge. Emerging standards such as AUTOSAR define a standardized interface to low-level software and, most importantly, introduce a new level of abstraction for feature implementation engineers.

This article refers to the address: http://

This improves the reusability of software components, but unfortunately there is little guidance on how to translate the results of model-based functional design into reliable and efficient system implementations in highly distributed environments.

In addition, there are very few articles discussing the physical end of the design process. This paper outlines a recommended system-level design methodology, including architectural design, network and task scheduling across multiple ECUs, harness design, and specification generation.

Why do you need AUTOSAR?

Even in the same company, “architectural design” has different meanings for different people, depending on which angle they stand. The physical architecture handles the physical aspects of the system, such as cabling and connectors, and the logical architecture defines the structure and distribution of intangible systems, such as software and communication protocols. The language of the current physical architecture and logical architecture is independent, which leads to the same meaning of the same word, and the design team and process are independent, which also leads to a very complicated design process (as shown in Figure 1).

 

Figure 1: The complexity of the physical and logical design flow leads to suboptimal design results. The correct function of the entire system is so difficult to implement that there is little time to find an alternative that can lead to a stronger, A more scalable and cost-effective solution. To implement such a solution, designers need new ways to tie the physical and logical design processes together and still allow different design teams to do their work.

The emerging AUTOSAR standard provides a technically and economically viable option for system-level automotive electronic/electrical design methodology, although it is primarily aimed at the software level, the design of logic systems. However, a large number of AUTOSAR metamodels and their rich interface definitions allow system-level electronic/electrical architects to express his design ideas in a standard format. Economically, the AUTOSAR standard opens up a vast, unified market that allows for the creation of appropriate design tools.

This paper describes a system-level design method consisting of point tools based on AUTOSAR. This leads to the entire process using standards in all meaningful places, but not limited to standards, or requiring users to adopt these standards.

How AUTOSAR works

The AUTOSAR standard was initiated by car manufacturers, suppliers and tool suppliers to standardize the open software architecture of automotive electronic control units (ECUs).

The AUTOSAR standard specifies a layered software architecture that clearly defines the interfaces between application software components (SWCs), user-visible car functions, and implementation of infrastructure components. It imposes strict rules on infrastructure components to allow components developed by different vendors to work together.

User-visible car functions are implemented through interconnected application software components. The SWC is the smallest unit that can be mapped to the ECU. In order to make SWC independent of specific hardware, the Virtual Function Bus (VFB) concept is defined, where SWC uses VFB to communicate with their environment.

This concept supports SWC repositioning to different ECUs, enhancing the reusability of application software.

An AUTOSAR system is basically defined by three XML files: SWC description, ECU resource description, and system configuration description. These files describe all aspects of a logical architecture: SWC, functional network, topology, and functional-to-ECU mapping. Although the syntax and semantics of these files are defined by the AUTOSAR standard, their method of creation is left to the tool vendor.

User case analysis

The following two representative user stories give you a deeper understanding of the complexities of overall physical and logical design tasks.

In the design flow shown in Figure 2, you can see how the logic design process drives the physical design process. The first step in this design process is the definition and implementation of automotive logic functions. Most OEMs break down the electrical system of a car into about 100-200 functions. Users create cell-level SWCs that express a variety of automotive functions, or call such SWCs from model design tools like Matlab/Simulink.

Since SWC specifications and development are highly fragmented in time and place, and many SWCs enter the design process from many different sources, consistency checks should be performed to detect errors as early as possible. Even if only the interface description is available, it is already possible to perform a static check of the interface consistency between internal components. At this point in the design flow, it is important to increase end-to-end timing requirements to support advanced analysis tools that require timing information in later processes.

Figure 2: User Case 1 - Logical Design Drives Physical Design At the same time, a potential topology can be created that outlines the logical topology of a distributed automotive network and describes the connections of sensors, actuators, and ECUs. Typically, a car project begins with the reuse of the original design and then modifies it. When reusing an existing ECU, very detailed ECU information can come from an enterprise database, or a new ECU needs to be defined, and its technical characteristics change during a specific period of development.

In both cases, both functional and topology information can be provided to the physical design flow. The functional level of the physical design process also requires data on the ECU (as used by the bus system). Today's physical design requires a subsystem design step in which subsystems such as ECUs and fuse boxes require further detailed design before the physical components are mapped to the package space (slots) in the car. In addition, at this step, the power/ground concept can also be developed.

The corresponding step in the logical architecture design is that the SWC is mapped to the ECU. This also determines the communication scheme between SWCs, that is, whether multiple SWCs communicate through a bus system or an internal ECU.

The choice of communication method has a direct impact on the physical design, which also increases the complexity of the entire design process. For example, this depends on whether wires, conventional wires, twisted pairs or twisted pairs are required.

The encapsulation step is followed by physical system integration, where the CAD system information is used to add additional physical information, such as the required in-line connectors and routing channels.

This in turn has an impact on the logical level of the design and again adds to the complexity of the entire design process. Too small routing channels may make it impossible to use twisted pair twisted pairs, or too long wire lengths may make relocating one SWC to another ECU a more cost effective alternative.

Once both physical and logical processes can provide results, their various data can be used to evaluate and optimize the automotive architecture. However, due to the complexity of the process, it is difficult to find more than one workable architecture. As a result, logic and physics designers can only try to optimize the parts of their design that they are responsible for.

Figure 3: User Case 2 - Physical Design Drive Logic Design Figure 3 shows the design flow for the physical design drive logic design, which is a derivative of the physical topology. Unlike the previous addition information, unnecessary information here needs to be filtered. For example, when a physical design of a cigar lighter is required, this function does not require a SWC description, so this information is not required in the logical domain. These two examples reflect only a small portion of today's existing design process challenges and illustrate the complexity of the entire process.

Integration of physical and logical design flows

One option for improving this inherently complex design process (multiple design teams working together on the same overall design) is the close relationship between the two different design flows.

Data needs to be synchronized throughout the design process, but at the same time, engineers are too much hindered by this synchronization. In the current workflow, all people share the same data objects and must check them before using them. An alternative workflow is to use two separate databases for two different design flows ( See Figure 4), but find a way to keep the data in sync without a lot of manpower.

This requires a design flow where most of the design is actually generated automatically, rather than manually generated. Changes in the database during the synchronization process will automatically lead to a "comprehensive" operation, completely avoiding the task of repeating previous efforts.

Figure 4: Parallel Processing Physical and Logic Design An example is the generation of a network configuration. When the signal that needs to be transmitted over the network changes, the designer can manually enter these changes and manually run all the necessary verification tests, which can lead to a prolonged design process for several months. In sharp contrast, various communication data can be automatically generated based on communication requirements and mathematical algorithms, which can greatly reduce the time required to complete the design process to the second level.

A similar physical design example is system integration. When the system changes (such as different routing channels), the manual process takes too much time and is prone to errors. By using an automatically generated process, changes to the system can be processed more or less immediately through the process. For example, the connector's mounting position change and wire length can be automatically generated. Here, the engineer's know-how is used to define rules, not to apply them.

Digital Control Attenuator

Digital Attenuator,Digital Step Attenuator,Digital Control Attenuator,Digital Variable Attenuator

Chengdu Zysen Technology Co., Ltd. , https://www.zysenmw.com