Model-Based Engineering with AADL

interface features set_speed: out data port; disengage: out event port; end interface; abstract implementation interface.pilot end interface.pilot;implementation interface.pilot end interface.pilot; abstract control features command_data: out data port; sensor_data: in data port; set_speed: in data port; disengage: in event port; end control;control features command_data: out data port; sensor_data: in data port; set_speed: in data port; disengage: in event port; end control; abstract implementation control.speed end control.speed; control components as we did in Table 3-1, we declare them as abstract. For this example, we assume there is a potential for decomposing the pilot interface into a complex interface unit. We could have made the sensor and actuator components abstract as well. However, to simplify the example and to demonstrate that you can mix abstract with runtimespecific categories, we maintain these components as devices. The declarations for this approach are shown in Table 3-2, where we have used the same partitioning and naming convention that is used in Table 3-1. Abstract components are represented graphically by dashed rectangles.implementation control.speed end control.speed; control components as we did in Table 3-1, we declare them as abstract. For this example, we assume there is a potential for decomposing the pilot interface into a complex interface unit. We could have made the sensor and actuator components abstract as well. However, to simplify the example and to demonstrate that you can mix abstract with runtimespecific categories, we maintain these components as devices. The declarations for this approach are shown in Table 3-2, where we have used the same partitioning and naming convention that is used in Table 3-1. Abstract components are represented graphically by dashed rectangles.