El compadrazgo, elección de los padrinos

According to the design, there are three things that need to be prepared before the evaluation: ontology for machines; the locations of instances of machines; machine hardware needs to be

simulated. To apply the research to different kinds of machines, a simple simulation environment is built. This platform offers a virtual environment to receive control instructions, update component states and send back state information.

i．

The ontology is built to describe machines according to the machine model discussed in chapter 5. The ontology has three main parts: machine, actuator, and sensor. Using XML the information represents machine model knowledge semantically.

The machine part of the ontology records category information and basic machine component data. Part of the information is shown in Figure 8.2. The information shows a machine hierarchy. For example, there is a category called “Light” under the category of “Home Equipment”. “Normal Lamp” and “Adjustable Intensity Light” belongs to the category of “Light”. Components of machines are also specified. <type> node in each <Component> node indicates the type of the component. For example, all the “Light” will have a sensor called “Light Intensity Detector”, and all the “Adjustable Intensity Light” will have an actuator component called “Light Intensity Controller” which is operated by a motor called “Slider”. For the purpose of the evaluation, models of three main categories are specified: home equipment, hospital equipment, and farm equipment. Machines in these categories are further grouped according to machine category knowledge.

Similarly, there are specifications of actuator and sensor information. The actuator ontology includes the information and instructions that are available for different types of actuators. Six types of actuators are modelled to support the evaluations. They are “Motor”, “Valve”, “Heater”, “Slider”, “OnOffSwitch” and “OpenCloseSwitch”. The sensor ontology includes all the sensor properties used in the evaluations, such as sensor type, initial value, and units. Nine types of sensors are defined: ” Light Sensor” (sensor used to measure light intensity), “Temperature Sensor” (sensor used to measure the temperature), “Moisture Sensor” (sensor used to measure the humidity), “Rotation Speed Sensor” (sensor used to measure the rotation speed of the motor), “Water Pressure Sensor” (sensor used to measure the water pressure), “Blood Pressure Sensor” (sensor used to measure blood pressure), “Electrical Pulse Sensor” (sensor used to measure pulse) and “Thermometer” (sensor used to measure human body temperature).

The machine models enable the system to reason about machines. Hence, the user only needs to tell the system instances of these machines. The code of all ontology models can be found in Appendix A.

Figure 8. 2 Example Of Machine Ontology

ii．

In the real world, different machine instances are located in different places. In order to demonstrate this, virtual locations are needed before the machines can be initialized. According to the design in chapter 5, machine descriptions on the remote machine servers store machine information that is used for control data exchanges. Therefore, these virtual locations can be represented using different directories on the machine server side. The data exchange with different machines is achieved by obtaining and updating the machine descriptions in these directories.

To create the scenarios, some directories are created dynamically according to the virtual locations. An XML file is used to map the links from different virtual locations to the

…

<machine>Home Equipment <machine>Intelligent Light

<Sensor>Light Intensity Detector

<operateBy>Light Sensor</operateBy> </Sensor>

<machine>Adjustable Intensity Light <Component>Light Intensity Controller <operateBy>Slider</operateBy> </Component> <Instruction>Bright Mode</Instruction> <Instruction>Evening Mode</Instruction> </machine> <Component>Switch <operateBy>OnOffSwitch</operateBy> </Component> </machine> <machine>Cleaning Devices <machine>Washing Machine <Sensor>Water Temperature <operateBy>Temperature Sensor</operateBy> </Sensor> …

directories. Later, machine descriptions can be stored in different directories to demonstrate the machine located in different places.

Figure 8. 3 Example Of Machine Location Mapping In XML Format

Figure 8.3 shows an example mapping. <location> represents a remote location connected to the server. <room> represents a sub-location within a <location>. <roomType> represents the type of sub-location. The example shows two locations: “Home” and “Hotel”. In the “Home” location there are several sub-locations such as “Kitchen”, Bed Room 1”, “Bed Room 2” and “Sitting Room”. Different simulated machines can be initialised to be in any of these different locations.

iii．

Before users are able to control a machine it needs to be machine simulation program which allows other software to access its embedded control APIs. There are two type of machine simulation program. One is for the real hoister hardware, another one is a simulation program. The hoister has its own embedded control program similar to other electronic devices. This control program is written by the vendor and offers a simple API for other programs to access the hoister. The machine simulation program for the hoister is developed to invoke these API when it receives simple command strings such as “go up”, “go down”, “go forward” and “go

…

<location>Home

<roomType>["Kitchen", "Bed Room", "Sitting Room"]</roomType> <room>Kitchen</room>

<room>Bed Room 1</room> <room>Bed Room 2</room> <room>Sitting Room</room> <room>Bath Room 1</room> <room>Bath Room 2</room> <room>Entrance Room</room> </location> <location>Hotel <roomType>["Room"]</roomType> <room>Room 101</room> <room>Room 102</room> <room>Room 103</room> <room>Room 201</room> …

backward”. These commands are described in MFD so that the Adapter Layer application can invoke corresponding hardware function. The hoister simulation program is programmed in java, C and C++. Using C and C++ program, the low level hardware control API is programmed in a DLL (Dynamic-Link Library) which can be invoked by the adapter program written in java. Then a simple java program invokes different hardware control commands when receiving different instructions.

Another machine simulation program simulates the machine embedded control programs that are executed on the hardware side, and cause the sensor value changes. It functions like a virtual machine. The hardware simulation program is described using an XML configuration file, and is executed dynamically according to the control message. The simulation description file has the same functions as MFD (chapter 5). The difference is that the description file is set for a group of machines as for a whole test example while MFD is set for each machine.

Figure 8. 4 Example Of Machine Hardware Simulation Configuration File …

<machine>BOSCH Dishwasher123

<function name="WaterSpray_Motor_direction_Clockwise()"> <component operatedby="Motor" value="Clockwise">

WaterSpray</component> <operation>

{"sensor_name":"Spinning speed","action_type":"=", "changevalue":"100"} </operation>

</function>

<function name="WaterSpray_Motor_direction_antiClockwise()"> <component operatedby="Motor" value="antiClockwise">

WaterSpray</component> <operation>

{"sensor_name":"Spinning speed","action_type":"=", "changevalue":"-100"} </operation>

</function>

<function name="WaterInlet_Valve_state_ON()">

<component operatedby="Valve" value="ON">WaterInlet</component> <operation>

{"sensor_name":"Water Pressure","action_type":"+", "changevalue":"1"} </operation>

</function>

Figure 8.4 shows an example of the simulation description file in XML format. <machine> indicates which type of machine the group of functions belongs to. A <function> node records the detail function information. The attribute “name” shows the hardware function name described in MFD; <component> shows the component information for this function; <operation> shows the action for the function in JSON. For example, when the system receives a control message from the user which is found in HDL to be “WaterSpray_Motor_direction_Clockwise()”, the first function node will be invoked. <component> indicates that this action will be operated by “WaterSpray” which is a “Motor” and the value is changed to be “Clockwise”. The details of <operation> specified to this function will set the value of the sensor attribute named “Spinning Speed” to “100”. This is to simulate the function when the direction of the water spray of a BOSCH Dishwasher123 is turned to “Clockwise” and the rotation speed of the water spray is changed to 100 rotations per second. The rotation speed value is then sent back to the system as a sensor value.

By mapping the commands in the description in the XML configuration file, the corresponding simulation program will be executed according to the descriptions in the <operation> items. Therefore, it demonstrates that when the machine server receives the control message, the machine hardware functions are invoked and some actions cause the change of machines sensor states.