6.6      Devices

(1)   A device component represents dedicated hardware within the system, entities in the external environment, or entities that interface with the external environment.  A device may represent a physical entity or its (simulated) software equivalent.  A device may exhibit simple or complex behaviors.  Devices may internally have a processor, memory and software that can be modeled in a separate system declaration and associated with the device through the Implemented_As property.  Devices are logically connected to application software components and physically connected to processors via buses.  If the device has associated software such as device drivers that must reside in a memory and execute on a processor external to the device, this can be specified through appropriate property values for the device.

(2)   A device interacts with both execution platform components and application software components.  A device can have physical connections to processors via a bus.  This models software executing on a processor accessing the physical device.  A device also has logical connections to application software components. Those logical connections are represented by connection declarations between device ports and application software component ports.  For any logical connection between a device and a thread executing application source text, there must be a physical connection in the execution platform. 

(3)   A device can be viewed to be a primary part of the application system. In this case, it is natural to place the device together with the application software components.  The physical connection to processors must follow the system hierarchy. 

(4)   A device may be viewed to be primarily part of the execution platform. In this case, it is placed in proximity of other execution platform components. The logical connections have to follow the system hierarchy to connect to application software components.

(5)   Examples of devices are sensors and actuators that interface with the external physical world, or standalone physical systems (such as a GPS) or dedicated hardware (such as counters or timers).  Devices communicate with embedded application systems through ports and connections and with the computing hardware through bus access.

Legality Rules

Category

Type

Implementation

device

Features

·         port

·         feature group

·         provides subprogram access

·         provides subprogram group access

·         requires bus access

·         provides bus access

·         feature

Flow specifications: yes

Modes: yes

Properties: yes

Subcomponents:

·         bus

·         virtual bus

·         data

·         abstract

Subprogram calls: no

Connections: yes

Flows: yes

Modes: yes

Properties: yes

 

(L1)      A device type can contain port, feature group, provides subprogram access, provides subprogram group access, bus access declarations, flow specifications, a modes subclause, as well as property associations.

(L2)      A device component implementation must not contain a subprogram calls subclause. 

(L3)      A device implementation can contain abstract, data, virtual bus, and bus subcomponents, bus access connections, a modes subclause, a flows subclause, and property associations. 

Standard Properties

-- Hardware description properties
Hardware_Description_Source_Text: inherit list of aadlstring
Hardware_Source_Language: Supported_Hardware_Source_Languages 
-- Properties specifying device driver software that must be 
-- executed by a processor 
Source_Text: inherit list of aadlstring
Source_Language: inherit list of Supported_Source_Languages 
Source_Code_Size: Size
Source_Data_Size: Size
Source_Stack_Size: Size
-- Properties specifying the execution properties of the device or its driver 
Dispatch_Protocol: Supported_Dispatch_Protocols
Dispatch_Trigger: list of reference (port)
Period: inherit Time
Compute_Execution_Time: Time_Range
Deadline: inherit Time => Period
-- scheduling properties
Time_Slot: list of aadlinteger 
Priority: inherit aadlinteger
-- Properties specifying constraints for processor and memory binding
-- for the device driver software
Allowed_Memory_Binding_Class: 
   inherit list of classifier (memory, system, processor)    
Allowed_Memory_Binding: inherit list of reference (memory, system, processor)
Actual_Memory_Binding: inherit list of reference (memory)
Actual_Processor_Binding: inherit list of reference (processor, virtual processor)
Allowed_Processor_Binding_Class: 
   inherit list of classifier (processor, virtual processor, system)
Allowed_Processor_Binding: inherit list of reference (processor, virtual processor, system)
-- protocol support
Provided_Virtual_Bus_Class : inherit list of classifier (virtual bus)
Provided_Connection_Quality_Of_Service : inherit list of Supported_Connection_QoS
-- mode related properties
Resumption_Policy: enumeration ( restart, resume )
-- Virtual machine layering
Implemented_As: classifier ( system implementation )
 

Semantics

(6)   AADL device components model dedicated hardware or physical entities in the external environment, e.g., a GPS system, or  entities that interface with an external environment, e.g., sensors and actuators as interface between a physical plant and a control system. Devices may represent a physical entity or its (simulated) software equivalent.  They may exhibit simple behavior, e.g., a timer, or complex behaviors, e.g., a camera or GPS.  Devices are logically connected to application software components and physically connected to processors. The device functionality may be fully embedded in the device hardware, or it may be provided by device-specific driver software. 

(7)   A device is accessible from a processor if the device is connected via a shared bus component.

(8)   A device declaration can include flow specifications that indicate that a device is a flow source, a flow sink, or a flow path exists through a device.

(9)   Device components can have different property values under different operational modes.

(10)  A device component can contain a data subcomponent to represent persistent state. This data subcomponent cannot be made accessible via data access. Device behavior can be specified via Behavior Annex subclauses, which can refer to the data subcomponent.

(11)  Embedded application software interacts with devices through port connections and through subprogram calls.  Data ports can be used to represent device registers.  Event and event data ports can be used to represent signals and interrupts that trigger execution of software or that initiate a reaction by the device.  Subprogram calls reflect functionality executed by the device.  This functionality may be fully implemented in the device hardware or through a device driver.

(12)  The Dispatch_Protocol property determines the execution behavior of the device.  A device can execute periodically or event-driven.  Periodic execution means that the device polls the external environment periodically to produce a periodic data stream to the application, or that it samples input from the application periodically.  Event-driven execution means that the device generates events, e.g., a clock or timer, that it observes events in the external environment and passes them to the application, e.g., flipping of a switch, or that it responds to events or event data being sent by the application, e.g., a signal to turn on a light.  The input or output rate on device ports can be specified through the Output_Rate property.  The Dispatch_Trigger property can be used to specify a subset of event or event data ports that can trigger a device dispatch.

(13)  The interface to a device may be through a device driver.  The features of the device type may represent the interface to the device via the device driver.  The execution behavior of the device driver is specified by the device dispatch protocol.

(14)  The device driver may execute as part of the underlying operating system kernel.  In this case, we can specify the driver characteristics as properties on the device itself, such as the code size, data size, and stack size.  Binding properties specify the processor whose runtime system includes the driver. 

(15)  The device driver may execute in a separate address space from the operating system kernel.  In this case, the binding property may specify a virtual processor as target.

(16)  A device driver may execute as an application thread.  In this case, the driver is modeled by an AADL thread.  This thread provides the device interface to the application and interfaces with the device registers of the physical device, represented by the AADL device component.

(17)  A device can contain a bus subcomponent that it makes externally accessible.  This models a bus that is managed by the device and other components can connect to it.  In this case the device is implicitly connected to this bus.

(18)  A device can support communication protocols as expressed by the Provided_Virtual_Bus_Class property.  Instances of such protocols can also be explicitly represented by virtual bus subcomponents.

(19)  The device is intended to be an abstraction of a physical component in the embedded system environment.  If it is desirable, the internals of the device can be modeled by AADL as a system in its own right, i.e., an application system and an execution platform.  For example, a digital camera as a device can be modeled as a set of processors and application software that handles the taking of images and their transfer from the camera to a processor via a USB bus connection.  This system implementation description can be associated with the device component declaration by the Implemented_As property (see Section 14).

Processing Requirements and Permissions

(20)  This software must reside as a binary image on memory components and is executed on a processor component. The executing processor that has access to the device must be connected to the device via a bus.  The memory storing the binary image must be accessible to the processor.  Device driver software may be modeled implicitly through the Source_Text and related properties, or it may be modeled explicitly by a separate thread declaration.

(21)  In the implicit model the execution of the device driver software may be considered to be part of the runtime system of a processor to which the device is connected, or it may be treated as an implicitly declared thread.

Examples

Package Equipment

with Buses, UserTypes, Simulation;

device Camera

features

  usbport: requires bus access Buses::USB.USB2;

  image: out event data port UserTypes::imageformat.jpg;

end Camera;

 

device temperature_sensor

features

  serialline: requires bus access Buses::RS232;

  temp_reading: out data port UserTypes::Temperature.Celsius;

end temperature_sensor;

 

device implementation temperature_sensor.hardware

properties

  Hardware_Description_Source_Text => ( “TemperatureSensorHardwareModel.mdl” );

end temperature_sensor.hardware;

 

device implementation temperature_sensor.simulation

properties

  Simulation::SensorReadings => “SensorTrace1.xls”;

end temperature_sensor.simulation;

 

device Timer

features

  SignalWire: requires bus access Wire.Gauge12;

  SetTime: in event data port UserTypes::Time;

  TimeExpired: out event port;

end Timer;

end Equipment;