ARTICLE IN PRESS
Computer Standards & Interfaces 2168 (2002) xxx – xxx www.elsevier.com/locate/csi
OPC-SMS: a wireless gateway to OPC-based data sources
2
Vassilis Kapsalis*, Stavros Koubias, George Papadopoulos
O O
F
1
3 4 5
Industrial Systems Institute, University Campus, Building A, Rion, 26500 Patras, Greece
PR
Received 15 April 2002; received in revised form 7 July 2002; accepted 12 July 2002
Abstract
7 8 9 10 11 12 13 14 15 16 18 17 19 20
This paper describes OPC-SMS gateway, a platform that integrates IP networks with the Short Message Service (SMS), in order to deliver an integrated service for access to data sources conforming to Object Linking and Embedding for Process Control (OPC) standard specifications, through SMS-enabled mobile devices. The gateway supports pull and push services in order to support both request-based and alarm/scheduled-based notifications, respectively. The proposed architecture is based entirely on the ubiquitous HyperText Transport Protocol (HTTP), Simple Object Access Protocol (SOAP), Extensible Markup Language (XML) protocols, and the Global System for Mobile communication (GSM) network and thus exploits the network infrastructure already in place. The capability of accessing different types of OPC data sources (real-time and historical) by any SMS-enabled device consists of a highly flexible service, supporting mobility and event-based notification. A pilot implementation of our approach has been tested in a large-scale installation for accessing OPC data sources of several automation subsystems in a hospital. D 2002 Published by Elsevier Science B.V.
EC
TE
D
6
R
Keywords: Gateway; Control networks; Internet; Distributed computing; Wireless access
R
21
1. Introduction
24 25 26 27 28 29 30 31
The ubiquity of Information Technology (IT) infrastructure makes it possible to seamlessly integrate distributed real-time applications across control networks, data networks, and the Internet. This integration becomes more compelling when real-time applications are associated with time-critical control data, as in the cases of industrial or building management systems. The integration of all these applications
U
N
C
O
22 23
* Corresponding author. Tel.: +30-610-910-299; fax: +30-610910-303. E-mail address:
[email protected] (V. Kapsalis). URL: http://www.isi.gr.
over different platforms provides new levels of flexibility and productivity, and becomes an option with many added values to modern enterprises. Industrial processes require both real-time monitoring and control, as well as access to historical data. Object Linking and Embedding for Process Control (OPC) is the dominant standard interface between different automation system vendors, enabling the connection of control networks with data/enterprise networks in a seamless and standard way [1]. OPC Data Access (DA) provides a standard mechanism for interacting with real-time data sources on the floor level of the factory. With OPC, hardware manufacturers have to make only one set of server software components to which customer’s client software can
0920-5489/02/$ - see front matter D 2002 Published by Elsevier Science B.V. PII: S 0 9 2 0 - 5 4 8 9 ( 0 2 ) 0 0 0 6 7 - 3
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
ARTICLE IN PRESS 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131
2. Related work
132
Several recent efforts have been proposed to address the issue of incorporating SMS capabilities for the remote monitoring and control of automation systems. The simplest approach is a solution that interconnects stand-alone devices with the GSM network, enabling the direct SMS-to-Input/Output (I/O) operation [11,12]. Under this approach, an automation
133 134 135 136 137 138 139
PR
O O
F
is quite restrictive, taking into account features like mobility and device independability. The rapid advances in mobile devices, wireless networking, and messaging technologies have given mobile users a number of choices for data communication and access to information and services. Short Message Service (SMS) [6] has become a mature communication service, primarily for person-to-person wireless messaging. Several distinct features of SMS such as alert capability (push functionality), ‘‘always-on’’ connection, simultaneous transmission with Global System for Mobile communication (GSM) voice, data, and fax services have resulted in a constantly growing rate of SMS communication. Recently, SMS has been integrated with e-mail and several other value-added services (request/response and push), such as Web access, retrieval of stock exchange data, weather information, headline news, home automation, etc. [7– 10]. In general, for each type of service, a separate module is responsible for retrieving the relevant information from the corresponding server and subsequently forwarding it to the mobile client. For example, in order to send notifications about newly received e-mails, a Simple Mail Transfer Protocol (SMTP) client periodically checks for new e-mails, which are forwarded as SMS messages, based on predefined rules (sender, priority, subject, etc.). In a similar way, a user may subscribe to a headline news service, in order to receive news updates for specific categories. Usually, this service retrieves live content from web sites by parsing (‘‘web scraping’’) web pages, in order to extract relevant information from the page sources. The corresponding module for this type of service is a HyperText Transport Protocol (HTTP) client with parsing capabilities based on configured scraping rules.
N
C
O
R
R
EC
TE
connect and exchange data on a very consistent way. Also, the standard interface makes system integration in a heterogeneous environment simpler, as an OPC client can connect to several OPC servers. OPC is based on Distributed Component Object Model (DCOM) software technology provided by Microsoft. Historical engines produce an added source of information that must be distributed to users and software clients that are interested in this information. In keeping with the desire to integrate data at all levels of a business, historical information can be considered to be another type of data. Until recently, most historical systems used their own proprietary interfaces for dissemination of data. There was no capability to augment or use existing historical solutions with other capabilities in a plug-n-play environment. This required the developers to recreate the same infrastructure for their products, as all other vendors have had to develop independently with no interoperability with any other systems. Recently, OPC Foundation, the organization that produces the OPC specifications, has published the OPC Historical Data Access (HDA) specification, which consist of a standard way by which automation applications, acting as OPC HDA clients, can access historical process data stored in various data sources [2]. The majority of commercially available Supervisory Control and Data Acquisition (SCADA) packets support OPC functionality within their operation framework, by hosting OPC servers and clients [3,4]. In general, OPC servers expose their functionality as a custom Component Object Model (COM) and/or Object Linking and Embedding (OLE) automation interface for use by several types of clients based on DCOM. Although these clients provide considerably advanced functionality, they work within the SCADA client framework usually as ActiveX controls. Also, they can be used over the Internet, by embedding them in Web pages in order to be viewed by ActiveXenabled browsers (e.g., MS Internet Explorer). Under this configuration, the communication between ActiveX clients and OPC servers is based entirely on DCOM, which may work over the Internet but is a platform-dependent solution, and furthermore, it has problems with firewalls and TCP ports [5]. Finally, these SCADA packets are PC-centric, requiring a PC or an embedded PC with an operating system (e.g., Windows 98, CE) on the client side. This requirement
U
47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
D
2
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221
222 223 224 225 226 227 228 229 230 231 232 233 234
D
PR
O O
F
open architecture standards that works seamlessly over wireless local networks and the Internet, thus, fully exploiting the ubiquitous wired/wireless network infrastructure. The OPC-SMS gateway is connected with the data sources (OPC servers) through the Internet by using the HTTP and Simple Object Access Protocol (SOAP) protocols. The OPC data sources (both real-time and historical data servers) are accessed by the corresponding OPC clients over DCOM, which are, in turn, exposing their functionality through appropriately developed wrappers, providing an entirely Web interface (HTTP-based), hosted by an Active Server Pages (ASP) framework. The OPC-SMS gateway initiates HTTP requests to Web applications, running in one or more Web servers, which implement the DCOM communication to the OPC servers, lying on the same local area network. Because of the ubiquity of HTTP, the OPCSMS gateway can be connected to several widely dispersed OPC servers through the Internet. Thus, one OPC-SMS gateway is capable of supporting a great number of OPC-based automation networks, provided that the gateway has an Internet connection with each of them. This is a unique feature resulting into highly scalable and expandable systems targeted into largescale (multi-site) applications with wireless connectivity requirements. Our solution overcomes the disadvantages of the DCOM- and CORBA-based architectures for Internet communication and is future-proof, based on the prevailing and/or emerging standards. Besides SMS, there are several proposed solutions for connecting mobile phones to Internet Protocol (IP) networks, mainly for surfing the Web.
N
C
O
R
R
EC
TE
device, e.g., a Programmable Logic Controller (PLC) with I/O capability, which is connected to sensors and actuators, is able to perform actions based on commands received by the GSM network. Furthermore, predefined events can cause notification alarms which are forwarded in the form of SMS messages to a mobile operator. Obviously, this approach fits into low cost applications with minor requirements regarding expandability and functionality. An alternative solution for medium-scale distributed architecture systems is the connection of an SMS server directly to a control network [13,14]. This approach is advantageous in terms of expandability, enabling the connection of several controllers over the same control network (e.g., LonTalk, X-10), which can be controlled through the same SMS server. It requires, however, a separate SMS server for each segment of the control network, thus restricting the effective range of SMS accessibility to spatially separated automation islands. A more advantageous solution for large-scale systems, capable of spanning several different control networks, is the use of a DCOM-based OPC client/ server connection, the de facto standard for interoperable industrial communications, over a local area network (e.g., Ethernet) [15]. Under this configuration, an SMS server, acting as an OPC client, at the local side, accesses data from several OPC servers, which are further transmitted to SMS devices, based on predefined rules. In effect, each DCOM-based network requires its own SMS server for connection with the GSM network. Although, the latter solution exploits the advanced features of the OPC standard (scalability, expandability, multi-vendor support, etc.), it experiences a number of disadvantages related to DCOM, regarding its platform/object dependence and the communication problems through the Internet, mostly due to firewall security restrictions. A similar approach is described in Ref. [8], in which applications at different locations communicate through an ‘‘interface broker’’ based on Common Object Request Broker Architecture (CORBA) [16]. This solution experiences disadvantages similar to the DCOMbased architecture, related to its firewall unfriendliness and the close relation to specific language platforms. In contrast with the above, the proposed OPC-SMS gateway consists of an integrated approach based on
U
140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187
3
Microsoft is implementing a microbrowser (Pocket Internet Explorer), which runs on Pocket PC devices, requiring the establishment of a data connection and logging to an ISP from cellular phones in order to access the Web [17]. UP browser from Unwired Planet (now Openwave) allows accessing Web pages written in Handheld Device Markup Language (HDML) [18]. Wireless Application Protocol (WAP) is a new protocol suite on top of mobile networks. New software has been developed for several mobile devices in order to browse Web pages in Wireless Markup Language (WML) format [19].
ARTICLE IN PRESS
3. System architecture 3.1. General description of OPC-SMS
288 289 290
The OPC-SMS gateway is an intermediate entity, which enables the communication between GSM networks and the Internet for accessing OPC data sources through SMS-enabled devices. It consists of two parts (Fig. 1):
291 292 293 294 295
296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326
EC
R
R
O
C
N
F
283 284 285 286 287
the main part residing in the gateway, which contains the communication module for the GSM network and the modules for the information access from OPC data sources, through the Internet the parts residing in the remote DCOM-based networks, which act as OPC clients, both for Data Access and Historical Data Access servers.
TE
All these technologies are different from the HyperText Markup Language (HTML) v4.01 specification, which is the standard for Web browsers [22]. Although most of them provide advanced features in terms of functionality, it is obvious that, in order to support all these disparate technologies, Web sites have to be rewritten in a number of different formats or a middleware has to be developed that would be able to reformat Web content based on the capabilities of each requested device. Both of these alternatives are costly and difficult to be supported effectively [23]. The complexity of all incompatible wireless technologies constitutes one of the main obstacles in the adoption of the mobile access to a large number of services [8]. WAP 1.2, a promising and robust standard, would be a proper technology solution due to its ‘‘always on’’ connection of the underlying General Packet Radio System (GPRS) network and the inherent support of push mechanisms for event notification messaging. However, the currently available WAP 1.2 devices are still expensive and hold a relatively small percentage share of the mobile phone market [24]. Furthermore, WAP 1.2 is closely related to GPRS, which, initially, is available on major transport routes and in large urban areas, requiring some time for full network coverage [25]. As of now, several commercially available mobile devices support WAP 1.1, which operates over circuit switched connections (GSM), implying a long connection set-up delay and time-based charging. In addition, the current GSM networks have very slow data transfer rates. SMS can be seen as the common denominator, which is a technology supported by all the mobile devices, from cell phones to Personal Digital Assistants (PDAs) and hand-held PCs. Compared with the above solutions, the approach of using SMS for accessing both real-time and historical data based on
the OPC DA and OPC HDA specifications, respectively, is transparent to Web sites and mobile devices. Currently, SMS can be considered as the most affordable solution with push capability and universal network coverage.
O O
3COM Palm VII introduced a notion, Web Clipping, where a set of predefined agents located on a Palm can interact with content providers [20]. The Web site responses are converted by a Webclipping proxy server into a form suitable for transmitting to the Palm VII. I-Mode, a packet-switched service offered by NTTDoCoMo, which is based on compact HyperText Markup Language (cHTML) [21].
PR
U
235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282
V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
D
4
In most existing implementations, SMS and IP networks are integrated through an SMS Center (SM-SC). In this case, a gateway interconnects the SM-SC to the IP network based on a specific protocol for communication between the SM-SC and gateway. Since the SM-SC is not part of the GSM specifications and its implementation is vendor-specific, the SM-SC-based SMS-IP integration solution heavily depends on SM-SC vendors. Furthermore, the SMSIP gateway is maintained and controlled by GSM operators, and thus requires the close cooperation with them in order to deploy new services. To address these issues and further support an environment for quick prototyping and hosting wireless data services, a solution transparent to the existing SM-SC and GSM network is proposed. In this architecture, a GSM-compliant modem that provides wireless access to the GSM network is connected through the RS-232 port to the OPC-SMS PC-based gateway (in this implementation a PC running Windows 98/Me/ 2000/XP or NT). Regarding the Internet connection, the OPC-SMS gateway adopted a pure HTTP-based approach; thus,
ARTICLE IN PRESS 5
PR
O O
F
V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
mechanism and protocols used by common Web browsers, and thus, there is no need to develop a different interface at the server side for supporting SMS-enabled clients. This results into a significant reduction in engineering costs for the development and support of different information interfaces and is best fitted in applications where the HTTP-based access through Web browsers has already been in use. The drawback of this browser-centric solution is that the returned results are mixed with their presentation formatting (HTML tags), and a special parser has to be developed in order to extract the useful information by applying ‘‘screen scraping’’ techniques. Furthermore, there is a waste of bandwidth caused by the HTML formatting tags, which comprise the data presentation part. Finally, any change concerning the presentation part requires a modification of the parsing application in order to extract the useful information [26]. The latter technological approach is based on the SOAP protocol [27] in which the SMS-OPC gateway acts as a SOAP client and initiates Extensible Markup Language (XML) formatting requests over HTTP to the corresponding SOAP server(s). The SOAP server parses the SOAP message and, based on the message content, uses the appropriate service(s) for the actual data access. The resulting data are formatted as an
N
C
O
R
R
EC
TE
fully exploiting the benefits of this ubiquitous protocol. Basically, there are two prevailing technology approaches for the implementation of the communication between the OPC-SMS gateway and the serverside applications, which are responsible for the access to the OPC servers. Both of them exploit the ubiquitous networking infrastructure and prevailing Internet protocols. The former approach is based entirely on Web communication protocols (HTTP, HTML), which are used by common Web browsers for accessing Web pages. Under this ‘‘Web page’’ approach, the gateway communicates directly with Web pages, in order to retrieve and post information. The requests initiated by the gateway are in the form of HTTP messages (GET and POST), which are processed by the ASPbased Web pages hosted at the server. These pages normally instantiate the appropriate component(s), which communicate directly with the OPC server(s) for accessing real-time and/or historical data. The resulting data are dynamically embedded into one or more HTML pages and returned to the requested client (OPC-SMS gateway), which is responsible for the appropriate processing (parsing, formatting) in order to transform the HTML data into a readable format for SMS devices. The great advantage of this approach is that the gateway exploits the same access
U
327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353
D
Fig. 1. System architecture.
354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
N
C
O
R
R
EC
3.2. Services of OPC-SMS gateway
U
F
There are several types of services provided by the gateway, including request-based access by a user sending an SMS requesting a specific information, event-based (push) notification based on predefined customized events, and time-scheduled transmission of information. . In the request-based access, a mobile phone operator sends a short message (SM) to initiate the reading or writing of some values from/to the corresponding OPC server(s). The OPC-SMS gateway processes the request and initiates the corresponding operation. The results (parameter values) are then forwarded to the requested client. . In the case of event-based (push) mode, an alarm condition or a predefined combination of events initiates a short message to the appropriate mobile phone. Parameters, such as alarm conditions based on specific events, the details of the user(s) to be notified, etc., are configured in an appropriate initialisation procedure. . In the time-scheduled mode, the transmission of a specific information about critical process parameters (e.g., transmission of a summary report once per day) is sent periodically to authorized personnel.
3.3. OPC-SMS gateway modules
O O
404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427
The OPC-SMS gateway has been developed as an agent-based middleware, which allows quick deployment of value-added services. The creation of new services is achieved by adding new dispatching rules and the corresponding Agent(s) that carry out the services.
This section presents a detailed description of the functionality of each module, as well as specific implementation details (Fig. 2). 3.3.1. Short Message Driver (SMD) This module is responsible for the communication task between the GSM network and SMS-OPC gateway, dealing with all the details of sending/receiving short messages to/from the GSM modem. This communication is taking place through a protocol, implemented using the SMS Attention (AT) command set. In effect, Short Message Driver (SMD) acts as an interface between the Agent Dispatcher (AD), which is part of the Proxy Server, and GSM modem. It receives incoming short messages from the COM port and passes these messages to the Agent Dispatcher. On the outgoing direction, it receives messages from the Agent Dispatcher and, after transforming them into short message format, forwards them to the GSM modem through the COM port. Another operation performed by the Short Message Driver is the segmentation of the messages received from the Agent Dispatcher in order to assure that the maximum SMS length is less than 160 octets. Thus, a message greater than 160 octets is segmented to a number of SMS packets, which are fed to a First-In, First-Out (FIFO) queue for sequential transmission.
PR
XML message based on the SOAP specifications and returned to the client. Based entirely on the Universal XML language specification [28], this approach is independent of the client type and has nothing to do with presentation rules (e.g., HTML forms) and specific data formatting. Using SOAP/XML-based platform provides an environment for decentralized distributed computing, enabling applications to seamlessly communicate through the Internet. Although the SOAP/XML approach is the preferred solution for new applications, it requires a lot of development work for the modification/rewriting of existing Webbased systems in order to separate the content from the presentation. In order to exploit an already developed ASPbased Web interface for accessing both real-time and historical information which has been described in Ref. [29], and at the same time, to experiment with the emerging SOAP/XML technologies, we developed two types of gateways: Web- and SOAP-based, which will be described in the following sections.
TE
381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403
D
6
3.3.2. Proxy server This is the main module of the OPC-SMS gateway, which consists of two functionally separated types of modules. The first is the Agent Dispatcher, which acts as the interface with the Short Message Driver, and the second consists of one or more Agents with each one implementing a different service. Each Agent communicates through the Internet with the corresponding server module, which implements the actual data access. As mentioned above,
428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
7
using a password for access to specific parameter information. An SMS message for real-time access is of the form:
486 487 488 489
Command fItemg fParameter 1g . . . fParameter Ng
R
R
EC
TE
D
PR
O O
F
where, ‘‘Command’’ is a string that corresponds to one of the actions (services) supported by the OPC DA and/or HDA servers, ‘‘{Item}’’ can be an automation point or a database parameter and the ‘‘{Parameter 1}’’– ‘‘{Parameter N}’’ can be a list of specific parameters for each service. The Agent Dispatcher invokes the appropriate Agent (resides within the Proxy server) corresponding to the SMS message and passes to it the message parameters. The mapping of SMS messages to the services (each service is implemented by a separate Agent) takes place in a mapping table. Developing new services is implemented by adding new entries in this table. At the end of the processing (that was initiated by an SMS message) performed by the appropriate Agent, the Agent Dispatcher receives the results and, subsequently, sends them back to the Short Message Driver.
N
two types of Agents have been developed: Web- and SOAP-based. 3.3.2.1. Agent Dispatcher (AD). This module dispatches the received SMS message (command) from the Short Message Driver to the appropriate Agent based on the SMS content. The Mobile Station ISDN number (MSISDN) of the mobile device (caller ID) is used to identify the user, providing a level of security in order to reject unauthorized access. An added level of security is implemented in the application level by
U
475 476 477 478 479 480 481 482 483 484 485
C
O
Fig. 2. Functional blocks of the OPC-SMS gateway.
3.3.2.2. Web-based Agent. A Web-based Agent consists of an HTTP client for accessing real-time or historical data from a Web server, which hosts dynamic (ASP) HTML pages. These HTML pages have the capability to instantiate the corresponding OPC modules (COM servers) and to dynamically update the returned OPC item values in the corresponding page fields. The information access is achieved as follows: the Agent initiates an HTTP request based on the specific information that the SMS device wishes to retrieve. For each SMS request initiated from the mobile device, the Agent creates the corresponding HTTP request message. For example, if an SMS device wants to retrieve the current boiler temperature, which corresponds to an OPC item of a specific subsystem, the Agent directs the HTTP request to the appropriate Web page, which is responsible for the access of this OPC server/group/item. This Web page, which has been constructed based on the ASP framework, instantiates a component, which lies between the Web server and the OPC DA server, and performs the actual access of the OPC item (Fig. 3). The current value for the OPC item is updated in
490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
D
PR
O O
F
8
TE
Fig. 3. Web-based access.
EC
532 the corresponding Web page and subsequently fed to 533 the requesting Agent. 534 The SMS message for retrieving the current value 535 for the boiler temperature is as follows:
N
C
O
R
This means that the mobile user wants to read (RD) the real-time (RT) value of the parameter boiler temperature (BTEMP). The HTTP request that was constructed by the Agent Dispatcher and subsequently forwarded to the Web-based Agent (based on the entries of the mapping table), in order to retrieve the current value for the boiler temperature, is of the form: http://www.mywebsite.com/OPCDA/GetValues. asp?OPCServer = Server1&OPCGroup =Group1& OPCItem = BoilerTemp. In order to extract the useful information out of the Web page, which is received by the remote Web site, the Agent performs a parsing operation before sending it back to the Agent Dispatcher. The parsing rules applied at the collected results comprise a screen scraping operation and require an exact knowledge of the HTML formatting for each Web page. In order
U
536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553
R
RD BTEMP RT
to guarantee a flexible and extensible system, the current implementation uses a customized filter (Web Parser), capable of supporting different types of information, by applying the appropriate parsing and reformatting operations. For these tasks, several methods for the filter actions have been implemented. These methods, which are based on specific search pattern schemes, will enable the filter to retrieve (extract) specific data only. They perform, among others, the following operations:
554 555 556 557 558 559 560 561 562 563
564 565 566 567 568 569 570 571 572 573 574 575 576
Extract text between text: information retrieval between specific pieces of text. For example, in the following HTML page (Fig. 4), which contains parameter values of a system (e.g., boiler temperature), the last temperature value lies between the text: ‘‘Current boiler temperature:’’ and ‘‘Updated on’’. In order to retrieve this value, the appropriate filter’s method is called as follows: BoilerTemp = WebParser.GetTextBetweenText(‘‘Current boiler temperature:’’, ‘‘Updated on’’), which returns the current boiler’s temperature (88 jC) in a variable called BoilerTemp.
ARTICLE IN PRESS 9
F
V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
PR
D
data (real-time or historical through the corresponding method calls of the OPC clients), formats them as an XML document, and finally, sends them back to the client as a response. According to the SOAP specification [27], method calls and input parameters need to be XML-encoded and enclosed in a SOAP envelope. The data access at the server side is achieved by the OPC clients, which are also used for the data access of the HTTP-based clients. The manipulation of the XML documents (e.g., reading, formatting, parsing, construction operations), both in the server and client side, are performed by means of the appropriate objects’ methods, which are capable of handling the XML Document Object Model (DOM), as illustrated in Fig. 5. The communication and XML processing was based on the low level Application Programming Interface (API) of the MS SOAP Toolkit 2.0. A typical SOAP request envelop for reading the current value of a specific item and the corresponding SOAP response are shown in Fig. 6. Our SOAP/XML implementation provides a subset of the functionality of OPC DA servers and has been based partially on the OPC XML draft specification version 0.31 [30]. Schemas are still in the draft phase and there will probably be some changes at the final version. As soon as this specification is available, we are going to properly modify our implementation in order to fully comply with the OPC XML standard. The SOAP server provides methods for accessing data that are stored in OPC HDA servers, too. Regarding the OPC HDA, since there is no specification from the OPC Foundation, a proprietary SOAP/XML implementation was followed. This implementation provides the functionality of commercially available OPC HDA servers. The main difference compared to the OPC DA access is that
TE
O
Boiler Temperature: Quality: TimeStamp:
R
R
EC
After the information extraction, the Agent forwards the resulting string to the Agent Dispatcher. In the current example, the SMS that will be constructed based on the received parameter values, and that will finally be sent to the mobile user, looks like:
C
596 597 598 599 600 601 602 603 604 605
Extract text from table cell: retrieves parameter values lying within a specific cell of a table. This method is used when the returned values are in a tabular form. Extract text before/after word: retrieves parameter values lying before/after a specific word. Remove text between text: returns a string with the specified piece of text removed from it. Extract paragraph: returns a specific paragraph from the current page. Replace text within string: replaces certain characters or words with others within a string.
88 degrees Celsius Good 7/8/2001 10:05:25
3.3.2.3. SOAP-based Agent. This type of Agent is a SOAP client, which initiates (posts) XML-formatted requests that correspond to the SMS content (Fig. 5). More specifically, the SOAP Agent uses the request initiated by the Agent Dispatcher based on an SMS message for the construction of an XML document, which is forwarded to the appropriate Web server’s endpoint, hosting a SOAP server. The SOAP server, parses the received SOAP envelope, processes the contained input request, accesses the corresponding
N
T1.1 T1.2 T1.3
U
577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595
O O
Fig. 4. Sample HTML page.
606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
PR
U
N
C
O
R
R
EC
TE
D
Fig. 5. SOAP-based access.
O O
F
10
Fig. 6. SOAP request/response messages.
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
F
O O
N
C
O
R
R
EC
TE
The system has been designed taking into account the requirements for easy modification/removal of existing services and the capability for the addition of new ones. An intuitive Web-based configuration tool takes care of the parameter settings for all the gateway modules, including GSM settings, service management (addition, removal and modification of services), user management, operating modes, as well as parsing filter configuration. The configurator follows a tree-like structure, providing access to all features of the gateway (Fig. 7). The configuration of the GSM module includes the settings of the GSM modem (COM port, MSISDN, initialisation string, baud rate, data bits, etc.), which may be attached to any available COM port, as well as
U
647 648 649 650 651 652 653 654 655 656 657 658 659 660 661
PR
646 4. Configurator
the segmentation parameters, such as the maximum length of a single message, etc. The configuration of the Agent Dispatcher includes the management of user access rights (per service item), as well as the mapping of each SMS message to the corresponding service. Developing a new service (e.g., adding a new automation item to be controlled/ monitored) is implemented by adding a new entry in the mapping table. Regarding the service management, a number of parameters are configured for each type of Agent (Web and SOAP). These parameters include the service type (read, write, or alert), queries for the Web (or SOAP servers), filter parsing rules, schedules for periodical push of information, and finally, eventbased notification rules. The filter configuration consists of parsing rules definition, which is created for each service, in order to perform the appropriate parsing and formatting of the returned results from the data sources (Fig. 7). Under the scheduled mode of operation, there is the capability to program the updating of each parameter
D
643 the client request includes parameters for the time 644 interval (start and end time) of the stored OPC item 645 values to be accessed.
11
Fig. 7. Configuration tool.
662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683
ARTICLE IN PRESS 12
in specific time instants and, subsequently, the push of the new parameter value to the predefined SMS device(s). In the event-based mode of operation, each parameter is checked periodically for value changes, and based on the configuration (deadband per item, etc.), the new values are transmitted (pushed) to the predefined SMS device(s).
Several critical parameters are constantly monitored for exceeding the predefined limits, in order to initiate the corresponding alarm notifications to authorized personnel. Under real working conditions, the most often use of the gateway is the immediate notification of alarms to SMS devices. This alarm message is usually followed by an operator-initiated acknowledgement, as a receipt of confirmation. Following the acknowledgement, the operator may request to receive the current values of other parameters, in order to have a more detailed view of the whole system’s operation status. Alternatively, the operator can choose to request the reading of the latest historical parameter values, in order to trace back the system operation and to evaluate more precisely the possible fault condition. A typical scenario for the gateway operation is as follows: an operator, responsible for the Water Pumping system, has been granted full access rights for monitoring and control of both real-time and historical values of the corresponding parameters (water level, pressure, flow-rate, pump state, etc.). Assuming that the high limit of the water tank level has been set to 2.4 m, an SMS alarm is sent to the operator’s mobile device each time that the level exceeds this limit. The SMS alarm message is of the form:
N
C
O
R
R
EC
PR
TE
The OPC-SMS gateway has been integrated in a large-scale project that included several automation systems within a hospital. The system is used for the monitoring and control of crucial units of the hospital, including the Boiler, Chiller, Electric Generator, Water Pumping, Lighting Control, and Oxygen Production Unit. Each subsystem consists of a number of automation controllers attached to I/O devices in order to perform sensor parameter measuring, data processing, actuator driving, and local/remote alarm notification. All controllers have networking capabilities and are able to communicate with each other in a distributed way, conforming to LonWorks (EIA-709.1) standard [31]. Each automation controller is loaded with an application code, in order to perform specific operations, according to the requirement analysis. A thorough description of the system, including operation details, can be found in Ref. [29]. Operational parameters, such as parameter set points, alarm limits, etc., can be changed through the network by using Standard Network Variable Types (SNVTs), without putting any controller offline, or detaching it from the network. These measured values are presented graphically both at the SCADA (inside the hospital network) and at the thin-client (Java based) applications (through the Internet), providing a view of the whole system status (parameter values and alarm signalling). Furthermore, the monitoring values and alarm states are stored in the central database as historical data for off-line processing. The OPC-SMS gateway makes both real-time and historical data accessible to mobile operators with SMS-enabled devices. This module works in parallel with the PC-based Man Machine Interfaces (MMIs) and adds mobility and wireless capabilities, augmenting the functionality of the whole system.
U
692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728
D
691 5. Pilot application and experimental results
O O
F
684 685 686 687 688 689 690
V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
WATER_LEVEL HI LEVEL ALARM! VALUE: 2.41 m 5.4.2001 10:23 Nxt(1),Prv(2),Ack(3),Q(4) As it is illustrated, the SMS message informs about the alarm condition and provides to the operator four reply options: Nxt(1) and Prv(2), for request of the next or previous parameter value, respectively, Ack(3), for confirmation of alarm receipt and Q(4) for stopping the conversation. The operator can acknowledge the alarm by sending an SMS message with ‘‘3’’ as content to the alarm originator. Furthermore, assuming that the next monitored parameters are the pressure, flow rate, and pump state, he can ask the current values for all of them. In response to his request, the gateway can send the following SMS: WATER_PRESSURE: 5.2 bar FLOW_RATE: 35 m^3/h
729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
WR PUMPIN OFF 784 The gateway relays the command to the correspond785 786 ing OPC item and acknowledges the operation with 787 the following SMS message:
ACK: PUMP_IN OFF 5.4.2001 10:26
C
O
R
R
EC
U
811 6. Conclusion and future work 812 813 814 815 816
F
TE
The above scenario highlights the benefits of the OPC-SMS gateway in everyday operation conditions regarding the immediate alarm notification, mobility support, and capability of monitoring/control of the automation subsystems. In order to keep the transfer delays low, the HTML pages are designed as simple as possible with a page size less than 5 Kb. Compared to the SOAP version, this size was 5 – 10 times larger than a corresponding XML-formatted message, resulting into higher transfer delays for the Web-based access. However, these differences in the delays were not practically noticeable, mostly due to the much higher delays of the SMS transmissions, which were in the range of several seconds. Finally, due to the close dependence of the Web-based version on the Web page formatting, certain changes of the HTML pages resulted in the appropriate reconfiguration of the Web Parser’s filtering actions.
N
788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810
O O
The operator notices that the inlet water pump is operating (ON), although the water level has exceeded the high level limit. This is an evidence of a fault condition at the level detection sensor. In order to avoid a tank overflow, the operator sends a command (Write operation) for stopping the water pump:
SMS-enabled mobile devices, supporting mobility and event-based notification. Based entirely on HTTP and SOAP/XML protocols, it overcomes the disadvantages of DCOM- and CORBA-based solutions and provides extensibility and scalability, targeted into large-scale (multi-site) applications, with wireless connectivity requirements. The platform has been designed as a modular Agent-based middleware with an API, which allows the quick deployment of new value-added services. The extensive use of ubiquitous and prevailing technologies makes this architecture future-proof and vendor/platform-independent. The Web evolves towards a model that separates information content from presentation by the use of XML-based encoding and the Internet; it is gradually shifted to a service-oriented distributed environment by extended use of Web Services. Under this transformation, totally XML-based information exchange between applications, in conjunction with client-specific Extensible Stylesheet Language (XSL), stylesheets that could tailor the information content to the unique needs of each client, would provide a framework for universal connectivity. In order to achieve this, emerging technologies like Composite Capabilities/Preferences Profiles (CC/ PP) [32], Extensible HyperText Markup Language (xHTML) [33], OPC XML [30], Web Services Description Language (WSDL) [34], Universal Description, Discovery, and Integration (UDDI) [35], and SOAP [27] would be appropriately incorporated and deployed in distributed architecture systems. This would lead to user-transparent middleware approaches, with advanced connectivity capabilities. In the framework of this evolution, our gateway could incorporate these technologies by appropriately modifying and/or extending the corresponding functional modules. Its modular architecture allows developers to write device drivers, information access methods, and application logic, in order to support any wireless network and transport protocol. However, most of the above technologies are still under development and, definitely, have to prove their value in real-life applications, before receiving wide acceptance/support from the industry. Currently, we are monitoring the progress of these technologies and may incorporate part of them in new gateway versions.
PR
PUMP_IN: ON 5.4.2001 10:24
D
775 776 777 778 779 780 781 782 783
This paper introduced the OPC-SMS gateway, an integrated platform for wireless access to real-time and historical OPC data sources through the Internet, based on open standards. The proposed architecture provides a transparent solution for wireless access to
13
817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
N
C
O
R
R
EC
F
O O
TE
[1] OPC Foundation, OPC Data Access Automation Interface Standard, v2.02, February 4, 1999. [2] OPC Foundation, OPC Historical Data Access Automation Interface Standard, v1.0, January 6, 2001. [3] Genesis GraphworX32 Version 6 manual, Iconincs, http://www.iconics.com. [4] Wonderware ActiveFactory http://www.wonderware.com/ WonderACT/actfactory.htm. [5] Y.M. Wang, W. Russell, A. Arora, A toolkit for building dependable and extensible home networking applications, Proc. 4th USENIX Windows Systems Symposium, August 2000. [6] ETSI/TC ‘‘Technical Realization of the Short Message Service Point-to-Point’’, v.4.6.0. Tech. Rep., Rec. GSM 03.40, 1993. [7] C.H. Rao, D. Chang, Y. Lin, iSMS: an integration platform for Short Message Service and IP networks, IEEE Network, (March/April 2001) 48 – 55. [8] C.H. Rao, D. Chang, Y. Chen, M. Chen, iMobile: a proxybased platform for mobile services, Proc. First ACM Workshop on Wireless Mobile Internet (WMI2001), Rome, July 2001. [9] V. Ghini, G. Pau, P. Salomoni, Integrating notification services in computer network and mobile telephony, Proc. SAC 2000, March 19 – 21 Como, Italy, 2000. [10] Derdack Software Engineering GmbH, ‘‘Message Master Business Editions Easily Wireless’’, http://www.derdack.com. [11] Falcom GmbH, Falcom A2(D)-3 User Manual Firmware GPS/ ALARM, http://www.falcom.de. [12] Klinkmann Automation, GSM-Control Software User Manual, http://www.klinkmann.fi. [13] http://www.mphone.se/mphone_eng/index1.htm. [14] H. Wang, B. Raman, C. Chuah, R. Biswas, R. Gummadi, B. Hohlt, X. Hong, E. Kiciman, Z. Mao, J. Shih, L. Subramanian, B. Zhao, A. Joseph, R. Katz, ICEBERG: an internet-core network architecture for integrated communications, IEEE Pers. Commun (2000), Special Issue on IP-based Mobile Telecommunication Networks. [15] Klinkmann Automation, GSM-Control Software OPC Version User Manual, http://www.klinkmann.fi. [16] Object Management Group, http://www.omg.org. [17] Microsoft Corporation, Pocket PC home page, http://www. microsoft.com/mobile/pocketpc/. [18] W3C, Proposal for a Handheld Device Markup Language, (HDML), http://www.w3.org/pub/WWW/TR/NOTESubmission-HDML.html. [19] Wireless Application Protocol Architecture Specification, WAP-210-WAPArch-20010712, Version 12-July 2001. [20] Palm, Inc., Web Clipping, http://www.palmos.com/dev/tech/ webclipping/. [21] iMode DoCoMo, http://www.nttdocomo.com/i/. [22] W3C, HTML 4.01 Specification, http://www.w3.org/TR/ html401. [23] S. Saha, M. Jamtgaard, J. Villasenor, Bringing the wireless internet to mobile devices, IEEE Computer, (June 2001) 54 – 58. [24] Melody, iSMS—Interactive and Personalized SMS Services with Existing Content, http://www.melody.se.
U
866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920
[25] S. Bisson, Dial ‘m’ for commerce, Application Development Advisor, (June 2001) 14 – 17. [26] Wrox Press Ltd., ‘‘Professional XML Web Services’’, 2001, http://www.wrox.com. [27] W3C, Simple Object Access Protocol (SOAP) 1.1, http:// www.w3.org/TR/SOAP. [28] W3C, XML home page, http://www.w3.org/XML/. [29] V. Kapsalis, A. Kalogeras, K. Charatsis, G. Papadopoulos, Seamless integration of distributed real time monitoring and control applications utilising emerging technologies, Proc. of the 27th Annual Conference of The IEEE Industrial Electronics Society, Denver, CO, USA, 2001, pp. 176 – 181. [30] A. Kowalczyk, ‘‘OPC – XML & .NET’’, presentation at ISA Expo 2001, http://www.opcfoundation.org/03 _ events/ pm6OPC + XML + dot-net.ppt. [31] Echelon Corporation, LonTalk Protocol Specification Ver. 3.0, (1994). [32] W3C, Composite Capabilities/Preference Profiles, http:// www.w3.org/Mobile/CCPP/. [33] XHTMLk 1.0: The Extensible HyperText Markup Language, http://www.w3.org/TR/xhtml1. [34] W3C, Web Services Definition Language (WSDL) 1.1, http:// www.w3.org/TR/wsdl. [35] Universal Description, Discovery and Integration (UDDI) v2.0, http://www.uddi.org.
PR
865 References
D
14
Dr. V. Kapsalis received a Diploma in Electrical Engineering and a PhD degree in Electrical and Computer Engineering from the University of Patras, Greece, in 1990 and 1994, respectively. Since 1990, he has been involved in several projects in the Department of Electrical Engineering, University of Patras and Institute of Biomedical Technology (INBIT), under the framework of European Union and Greek programmes. During that period, he has developed systems and applications for process control, home/building automation, and telemedicine applications. Currently, he is a Senior Research Engineer in the Industrial Systems Institute (ISI), working on research projects supported by the Greek General Secretariat of Research and Technology and the European Union and joint projects with the Greek industry. His research activities include real-time MAC-layer protocols, industrial and home/building networking systems, distributed control architectures, network integration, and Internet technologies.
921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969
ARTICLE IN PRESS V. Kapsalis et al. / Computer Standards & Interfaces 2168 (2002) xxx–xxx
U
N
C
O
R
R
EC
F
O O
TE
1022
Professor George Papadopoulos, is a professor in the Department of Electrical and Computer Engineering at the University of Patras and Director of the Applied Electronics Laboratory. Recently, he has been appointed as director of the Industrial Systems Institute (ISI). His degrees, PhD in EE and MSEE, were obtained from the Massachusetts Institute of Technology (MIT) and BEE from the City University of New York. His main research interests include the following areas: microprocessor-based and embedded system design, computer communication networks (protocol software and internetworking), communication electronics, fieldbus-based industrial control, integrated industrial information systems, real-time kernels for industrial communications, home and building information systems, and machine vision for industrial products inspection. He has participated as coordinator, partner, or subcontractor in many projects of the EU. Finally, as director of the Applied Electronics Laboratory and Industrial Systems Institute, he has been collaborating with many Greek industries through direct contracts. The majority of these grants and contracts are in the areas of embedded telecommunication systems and industrial information systems.
PR
Prof. S. Koubias received a Diploma in Electrical Engineering and a PhD degree from the University of Patras, Greece, in 1976 and 1982, respectively. Since 1999, he has been an Associate Professor in the Department of Electrical Engineering of the University of Patras, Greece. From 1976 to 1999, he was a Research Associate, Lecturer, Assistant, and Associated Professor at the Department of Electrical Engineering, University of Patras, Greece. Since March 2001, he has been the Director of the Network Operation Center (NOC) of the University of Patras. Since June 1998, he has been a member of the Industrial Systems Institute (ISI) of Patras. His current research interests include real-time communication protocols, industrial networking systems, wireless networks, multimedia communications, embedded systems, advanced microprocessor architectures, and home networking systems. He has participated as coordinator and partner in many Greek and European R&D programs. He has published over 90 papers in miscellaneous international journals and conference proceedings. He has also written books and course notes in industrial networks, microprocessors, and microcontrollers. Prof. Koubias is a member of the IEEE and Technical Chamber of Greece (TEE).
D
971 972 970 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995
15
997 998 996 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021
