Advances in Automotive System Modeling: EAST-ADL (Part 1): Page 4 of 6

May 16, 2013 //By DeJiu Chen, KTH; Lei Feng, Volvo; Henrik Lönn, Volvo; Juha-Pekka Tolvanen, MetaCase
Advances in Automotive System Modeling: EAST-ADL (Part 1)
For decades developers of automotive embedded systems have enjoyed the benefits of modeling. Models have not only served communication and gaining better understanding but are also used to prototype, analyze, simulate and test the developed systems. With dedicated generators it has also been possible to produce production-quality software code from the models. Typical cases of code generation are various control-engineering solutions and infotainment systems with HMIs.
requirements already presented in the feature model (Figure 2). This is because as the ABS_1 function, together with other functions for wheel speed monitoring, ABS control, brake torque actuation on each of the four wheels, constitutes the control loop that realizes the ABSBraking feature. The ABSBraking feature specialises the AdvancedBraking feature and thereby inherits the requirements. Based on EAST-ADL, the tool support enables tracing to see for example which are all the features and functions that satisfy a particular requirement. The mapping and trace to requirements can be specified in functional architecture models as in Figure 3, or in separate views as in Figure 4, showing functions satisfying particular requirements.

Figure 4. Requirements satisfied by functions of regenerative breaking in MetaEdit+ tool. For higher resolution click here .

Moving to design architectures

The concrete realization of the abstract functionality is first considered in a technical architecture specification, referred to as functional design architecture. It specifies the refinements of analysis architecture for the realizations on a particular software and hardware platform (e.g. through partitioning and allocations of the abstract application functions). An illustration of this is shown in Figure 5. Here BrakeRR design function receives three different kinds of data: requested torque , wheel speed and vehicle speed . This function is connected to a local device manager sending the signal to the hardware function. This hardware function then provides the physical energy to BrakeTorque_RR.

Figure 5. Design functions of regenerative breaking. For better resolution click here.

In parallel with functions, EAST-ADL allows designing hardware architecture, consisting of sensors, actuators, power supplies and ECUs. Figure 6 shows a part of the hardware architecture where BrakeRR function from functional design in mapped to HW architecture. Sensor Encoder_RR provides Revolutions Per Minute via IOConnection to ECU_RR node which then sends the requests to the brake located in rear right. All the hardware components have an in port for power. ECU node component

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.