When control commands are sent to the adapter, it will be forwarded to MAA and then corresponding hardware functions can be invoked. Even when semantic messages are understood by the adapter but without the understanding of corresponding hardware functions, it is difficult to execute the correct commands. MFD is designed to solve this problem. This section will introduce how MFD works to solve this problem.
Figure 5.6 Machine Function Description Example For An Intelligent Light
MFD can be considered as a “map” for the MAA to find the right function in the controlled machine. It is represented using semantic language, so that it can be understood and analysed by MAA. MFD is designed to be generated by manufactory that produces the machine so it is hard to find a unified structure for MFD because different machines have different hardware
<?xml version="1.0" encoding="UTF-8" ?> <root>
<machineID>000017</machineID>
<machineType> Intelligent Light</machineType> <manufacturer>Panda</manufacturer> <function_maps> <function name="Brightmode"> <hardwareFunction> <name>updateUWORD</name> <parameter>{0x00096857, 0}</parameter> </hardwareFunction> </function> <function name="LightSlider_Slider_state_UP">
<component operatedby="Slider" value="UP">LightSlider</component> <hardwareFunction> <name>updateUWORD</name> <parameter>{0x00096820, 0}</parameter> </hardwareFunction> </function> <function name="LightSlider_Slider_state_DOWN">
<component operatedby="Slider" value="DOWN">LightSlider</component> <hardwareFunction> <name>updateUWORD</name> <parameter>{0x00096820, 1}</parameter> </hardwareFunction> </function> …
functions. For example, some machine will have to write data on certain memory address while some machines will invoke certain kind of hardware functions. No matter what it is, the rules for creating MFD are the same. That is, there are three things need to be described: “function name”, “component” “hardware function”. “Function name” is the name of the function which can be referenced in the control message. “Component” indicates the actual actuator that operates the function, including its state. “Hardware function” is the description of actual hardware function that invoked. This description will be various according to different control machines.
An example of MFD is given in Figure 5.6. There is some general information which is initialised when the machine is produced: <machineID> represents a unique machine identifier; <machineType> represents what the machine type is; <manufacturer> represents the company that produces the machine. Additionally, there is important information which will help to map control hardware function to corresponding machine actuator. Each sub node <function> of the node <function_maps> will map hardware functionality using its attributes. The “name” attribute represents the hardware control function name that can be identified by MAA. The sub node <component> will specify the actuator or sensor and corresponding attributes it is aiming to change or get for the hardware. The node <hardwareFunction> will include the details of the hardware functions that the machine can execute.
In the example, the description represents the function mapping information of an intelligent light with ID 000017. From the basic information it is not difficult to ascertain that the intelligent light is produced by a company called “Panda”. There are five atomic hardware functions for the intelligent light control, such as “LightSlider_Slider_state_UP” and “LightSlider_Slider_state_DOWN”. From the function map, it is easy to find “LightSlider_Slider_state_UP” will be invoked when the component named “LightSlider” is activated and it aims to change the attribute of the actuator “LightSlider” value to “UP” with the hardware function name “updateUWORD” with a pair of parameters ”{0x00096820, 0}”. “0x00096820” represents the memory address and “0” is the value need to be set in this address when the instruction is activated.
With the help of MFD, the execution of control commands can be processed as shown in Figure 5.5. When a control command is received by the adapter, ACH will require FRH to analyse MFD to get the right hardware function description and send it to MAA. Then, MAA
will process the information in a message to Hardware Control Program (HCP). Once HCP get the message, it will invoke corresponding hardware functions, such as reading and setting certain memories, to finish the control task. Although the content of the node <function> can be changed according to different manufacturers, as soon as they are pointed to the right hardware function and can be understood by the hardware control program the command can be processed correctly.
This description is supposed to be generated by the manufacturer who produces the machine. As soon as it can be downloaded to local machines using the machine driver program, it will be invoked and updated by FRH. The hardware upgrade program will responsible for future updating. The fact behind it is the machine hardware function as well as their relationships with the machine components can be described semantically according to the machine model. In this way, no matter how the control logic changes the system is able to understand and dynamically invoke machine hardware. Even if the hardware function changes in the future, no more change is needed except updating the description.