## 2 Architecture
### M2M Gateway Resource Control and Management
#### 2.2.1 Resource Definition
\begin{table}
\begin{tabular}{c c c} \hline \hline
**URL Description** & **Description** & **Description of Specific Function** \\ \hline /stations & GET & list of information about all substations \\ \hline /stations/\{stationed\} & GET & display the information for stationed \\  & PUT & update information about the stationid \\ \hline /stations/\{stationed\}/plcs & GET & list information about all PLCs for stationid \\  & PUT & update information about all PLCs for stationid \\ \hline /stations/\{stationed\}/plcs/\{plcid\}/\{sensorid\} & GET & display information about sensorid in plcid for stationid \\  & PUT & update information about sensorid in plcid for stationid \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Simple description of the resource interface. According to the simple description of the resource interface in Table 7, the data exchange with the sensor occurs in the bottom layer, _i.e._, the read and write operations on the sensor, as shown in Table 8.  
When the client end sends a message to the server resource, the M2M gateway parses the resource information requested by the URL, and then provides the field information. The procedure is shown in Figure 2.  
As shown in Figure 2, after the data access layer receives the data request from the client end, it parses the URL and then parses the field, which may include the sub-station number, the number of the PLC used, and the sensor number. This information is compared with the resource operation table. If it is determined that the operation is legal, all the field information will be encapsulated into a data object, which is then transferred to the resource adaptation layer. If the operation is illegal (e.g., a writing operation to a read-only sensor), an error message will be returned. The resource operation table is the simple regulation and definition of the resources on the server. It specifies the form of resource access for the client end. A simple example of the description of a resource operation table is shown in Table 9. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Resource Name** & **Resource Method and ID** & **Examples** \\ \hline read data from & GET & http://localhost:8080/HeatingSystem/ \\ certain sensor & /stations/\(\{\)stationed\(\}\)/\(\{\)plcs/\(\{\)plcid\(\}\)/\(\{\)sensorid\(\}\) & service/stations/1/1/D2000 \\ \hline write data to & PUT & http://localhost:8080/HeatingSystem/ \\ certain sensor & /stations/\(\{\)stationed\(\}\)/\(\{\)plcs/\(\{\)plcid\(\}\)/\(\{\)sensorid\(\}\)/\(\{\)value\(\}\) & service/stations/1/1/D2002/80.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Resource information comparison. Figure 2: Flowchart to handle the data request. Table 9 is a simple description of the resource operation table, where stationid is the number of the production base, plcid is the number of the PLC used, sensorid is the number of the sensor, type is the type (where 1 is readable only, and 2 is readable and writable), high is the upper limit, and low is the lower limit. With respect to read-write sensors, when the client end sends a message to the gateway data, the data access layer parses the request of the user and inspects the resource operation description table. If it recognizes that the operation is legal, it will encapsulate it as a data object in XML format, as follows: \begin{tabular}{|l l l|} \hline \(<\)?XML version= \"1.0\" encoding= \" UTF-8\"?\(>\) \\ \(<\)DataService\(>\) \\ \(<\)StationId\(>\)1\(<\)/StationId\(>\) \\ \(<\)PlcId\(>\)1\(<\)/PlcId\(>\) \\ \(<\)SensorId\(>\)100\(<\)/SensorId\(>\) \\ \(<\)Value\(>\)58.5\(<\)/Value\(>\) \\ \(<\)/DataService\(>\) \\ \hline \end{tabular}   
After the M2M gateway processes these requests, the data are exchanged with the sensor through relevant techniques, and the data required by the client are obtained. These data are encapsulated into an XML format file and then sent back to the client.