Blank 01

Architecture Overview
To facilitate the development of MassWare supported vehicle applications, an XML-based system script file is provided for application developers or end users to customize the application configuration and adaptation policies. In particular, the script file can be divided into a declaration part and an adaptation-rule part (see Fig. 10). The declaration part declares all masslets and masstools – components used in a local program and middleware agent. The detail of a component declaration is shown in Fig. 5. Based on the declaration, the MassWare agent loads and instantiates the components by the component-level reflection, and initializes them with the provided parameters. The adaptation-rule part contains adaptation policies and each policy can be further separated into three sections: a sensor, a proactive actuator, and an optional reactive actuator. The sensor section can be parsed by the event interpreter to build an event sensor that monitors interested contexts and accepts the subscription of the proactive actuator declared in the proactive actuator section. The proactive actuator section describes the system architecture-information that is used to update the actuator internal states by the reconfigurator when it performs reconfiguration actions. Therefore, the system behaviors can be dynamically adapted to the context changes through the MassWare system-level and component-level reflection (respectively, architecture reconfiguration and parameter tuning). The reactive actuator section describes the architecture-information of an actuator in peer agents that processes the received data from the proactive actuator, so that the behaviors of the proactive and reactive actuators can be synchronized in distributed vehicle systems. For the image transmission example discussed above, the component chains in proactive actuators prepare and send video frames and the chains in reactive actuators receive and display the frames. There are four marchlets (Grab, Compress, Decompress, and Display components), two awaretools (available bandwidth and CPU measurement tools), and two awarefuns (average and minimum functions). The application behavior can be dynamically reconfigured by using or not using the Compress marchlet according to the two adaptation polices, e.g. the first policy means that when the average available bandwidth in the last 5 seconds is less than 10Mbps, the sensor notifies the reconfigurator to active the proactive-actuator that connects the Grab and the Compress components for reconfiguration.

Architecture Overview

To facilitate the development of MassWare supported vehicle applications, an XML-based system script file is provided for application developers or end users to customize the application configuration and adaptation policies. In particular, the script file can be divided into a declaration part and an adaptation-rule part (see Fig. 10). The declaration part declares all masslets and masstools – components used in a local program and middleware agent. The detail of a component declaration is shown in Fig. 5. Based on the declaration, the MassWare agent loads and instantiates the components by the component-level reflection, and initializes them with the provided parameters.

The adaptation-rule part contains adaptation policies and each policy can be further separated into three sections: a sensor, a proactive actuator, and an optional reactive actuator. The sensor section can be parsed by the event interpreter to build an event sensor that monitors interested contexts and accepts the subscription of the proactive actuator declared in the proactive actuator section. The proactive actuator section describes the system architecture-information that is used to update the actuator internal states by the reconfigurator when it performs reconfiguration actions. Therefore, the system behaviors can be dynamically adapted to the context changes through the MassWare system-level and component-level reflection (respectively, architecture reconfiguration and parameter tuning). The reactive actuator section describes the architecture-information of an actuator in peer agents that processes the received data from the proactive actuator, so that the behaviors of the proactive and reactive actuators can be synchronized in distributed vehicle systems.

For the image transmission example discussed above, the component chains in proactive actuators prepare and send video frames and the chains in reactive actuators receive and display the frames. There are four marchlets (Grab, Compress, Decompress, and Display components), two awaretools (available bandwidth and CPU measurement tools), and two awarefuns (average and minimum functions). The application behavior can be dynamically reconfigured by using or not using the Compress marchlet according to the two adaptation polices, e.g. the first policy means that when the average available bandwidth in the last 5 seconds is less than 10Mbps, the sensor notifies the reconfigurator to active the proactive-actuator that connects the Grab and the Compress components for reconfiguration.