Towards a Time-Constrained Web Service Infrastructure ... - CiteSeerX

Towards a Time-Constrained Web Service Infrastructure for Industrial Automation Markus Mathes, Steffen Heinzl, Bernd Freisleben Department of Mathematics and Computer Science, University of Marburg Hans-Meerwein-Str. 3, D-35032 Marburg, Germany {mathes,heinzl,freisleb}@informatik.uni-marburg.de

Abstract This paper suggests to seamlessly adopt a serviceoriented architecture based on web services throughout an industrial enterprise as a standardized, homogeneous communication backbone, from the business layer down to the manufacturing layer. Since manufacturing processes typically have time constraints, especially real-time constraints, particular attention has to be paid to the description of such time constraints within a web service and the timely execution of time-constrained web services within the proposed infrastructure. Furthermore, an outline of the Time-Constrained Services (TiCS) framework – a framework which empowers automation engineers to develop, deploy, publish, compose and invoke timeconstrained services – and a prototypical implementation of two main components of the TiCS framework, namely the TiCS Wizards and the TiCS Real-time Repository, are presented.

1. Introduction The software infrastructure of today’s industrial enterprises in the manufacturing domain, e.g. vehicle manufacturing and aircraft construction, is often organized in three vertical layers – business layer, intermediate layer, and manufacturing layer. The business layer of an enterprise contains software functionality for planning purposes, e.g. accounting, administration, or human resources. Large-scale enterprises by the majority and small and medium-sized businesses increasingly use enterprise resource planning (ERP) solutions at this layer. For interoperability reasons, current ERP solutions are based on web services, which enable a horizontal integration of the enterprise with its suppliers and customers and a flexible adaptation to new market conditions. Another benefit of adopting web services at the business layer is the possibility to publish business logic in a coarse-grained manner, which leads to simplified engineering and reengineering of business processes. The intermediate layer acts as a mediator between the

business layer and the manufacturing layer. It performs two major tasks: (1) Production orders on the business layer are translated into concrete control commands for the manufacturing systems, e.g. throughput increase/decrease, or shutdown for the purpose of service or retooling. (2) Manufacturing data from the shop floor, e.g. the system status of an assembly line, already produced units, or error messages, are collected, filtered, merged, and delivered to the business layer. The interconnection between business and manufacturing layer is realized via a so-called manufacturing execution system (MES). The particular MES used depends on the automation solution adopted at the manufacturing layer. In practice, the automation solution used also prescribes the used MES. At the manufacturing layer, the core business of an industrial enterprise is located – the manufacturing process. Modern assembly lines are composed of numerous, standardized units, e.g. industrial robots, grinding machines, conveyor belts, or paint shops. These units are controlled by Programmable Logic Controllers (PLCs) and Industrial PCs (IPCs) and are interconnected via field buses. The software on this layer is often proprietary and bundled with the hardware used. To summarize, the IT infrastructure of industrial enterprises in the manufacturing domain is highly heterogeneous, ranging from the business layer with standardized, web service based ERP solutions to the manufacturing layer utilizing vendor-specific automation solutions. The described layered architecture is shown in figure 1. A crosscutting concern of all three layers is the execution time of a layer-specific process. For example, if a customer order arrives at the business layer, it is necessary to initiate a corresponding production process at the manufacturing layer. To keep the promised date of delivery, it is necessary that each step in the production process is completed within the time constraint defined by the overall business process. In other words, a business process is decomposed into several sub-processes which are performed at the intermediate layer or at the manufacturing layer and which have to satisfy time constraints given by the overall

Business Layer

Vertical Integration

Enterprise Resource Planing (ERP) Supplier

Customer

Intermediate Layer Manufacturing Execution System (MES)

Manufacturing Layer vendor-specific automation soft- and hardware

Enterprise Boundary

Enterprise Boundary Horizontal Integration

Figure 1. Organizational layers of an industrial enterprise. business process. Time constraints at the business layer have a completely different scope than time constraints at the manufacturing layer: at the business layer, minutes, hours or days are sufficient to complete a process, whereas at the manufacturing layer, microseconds, milliseconds or seconds are required. Real-time execution is required on all layers, i.e. tasks are completed correctly within a given time constraint [9]. The vertical adoption of service-orientation in all three layers is desirable, since it leads to a homogeneous communication infrastructure based on a single communication paradigm within the entire enterprise [7]. However, due to the fact that most hard- and software at the manufacturing layer is significantly different from the hardand software at the business layer and automation engineers are usually not familiar with the implementation, deployment, and composition of web services, the overall adoption of service-orientation in an industrial enterprise is currently very challenging. This paper has two main contributions: (1) we show how the gap between the business layer and the manufacturing layer, i.e. the service-oriented and non serviceoriented world, can be bridged; (2) we outline the TimeConstrained Services (TiCS) framework which supports the convergence of the service-oriented business layer and the non service-oriented manufacturing layer. This framework is supposed to empower automation engineers to develop time-constrained web services independent of a web service domain expert, which may lead to enormous cost savings. The rest of the paper is organized as follows. Section 2 discusses the state-of-the-art in industrial automation and presents our proposal. In section 3, an architectural blueprint of the TiCS framework is presented, focusing on the TiCS Wizards and the TiCS Real-time Repository. Section 4 shows how TiCS can be used. Related work is discussed in section 5. Section 6 concludes the paper and

outlines areas for future work.

2. Industrial Automation: Past and Future This section presents our proposal to use web services as a communication backbone throughout an industrial enterprise, from the business layer down to the manufacturing layer. For this purpose, the status quo of industrial automation is described briefly. Afterwards, the challenges of using web services at the manufacturing layer are identified and possible solutions are presented. 2.1. Status Quo The main hardware used today to control the production process at the manufacturing layer are Industrial PCs (IPCs) and Programmable Logic Controllers (PLCs). An IPC is comparable to a regular desktop PC with respect to computing power and main memory, but the case design is much more robust to resist the hostile physical conditions in the manufacturing layer like temperature, vibration, or dust and dirt. Often, standardized operating systems like Microsoft Windows and Linux are used to run IPCs. A PLC is specialized hardware which differs heavily from common desktop PCs. Even though modern PLCs become more and more powerful, they are not comparable to desktop PCs with regard to computing power or main memory. A PLC has several input/output modules, which are connected to sensors and actuators, respectively. A sensor collects (often analogous) information from the shop floor, e.g. temperature, pressure, or humidity, whereas an actuator allows to manipulate the manufacturing process. Examples for actuators are electric motors, solenoids, or conveyor belts. A PLC operates in a loop where each step is processed in a predetermined time: it reads input data from its sensors, computes the necessary reaction based on a given rule base, and uses its

higher layers

Non Safety-Critical Web Service

Industrial PC

Monitoring Web Service

higher layers Real-time Web Service Engine Real-time Programming Language

Proprietary Interface

Real-time Operating System

Industrial PC Programmable Logic Controller

Programmable Logic Controller Function Input

Sensor

Processing

Maintenance Function

Safety-Critical Control Function

Non Safety-Critical Control Function

Monitoring Function

Output

Actuator

Sensor Sensor Sensor

(a) Automation based on IPCs and PLCs.

Actuator Actuator Actuator

(b) Exposing PLC functions as web services.

Figure 2. Industrial automation: past and future. actuators to react. Such a control loop (input-processingoutput) is called a (PLC) function. Since each step in a control loop can only take a predetermined time, a PLC inherently supports real-time processing. The rule base is set up by a domain expert, namely the automation engineer who maintains the manufacturing process, using different (low-level) programming languages, e.g. Function Block Diagram (FBD), Ladder Diagram (LD), Structured Text (ST), or Sequential Function Chart (SFC), as defined by IEC 61131-3 (http://www.iec.ch/). IPCs and PLCs are normally organized hierarchically, i.e. one IPC is interconnected with several PLCs for controlling and monitoring purposes. The interaction between IPC and PLC is organized by a vendor-specific software, which is bundled with the used PLC. Such a software often permits to call a PLC function from higher layers via proprietary protocols. Figure 2(a) shows the described structure. Figure 2(b) shows our proposal for using web services at the manufacturing layer.

To clarify the interaction of IPC and PLC to control the production process, we will now look at an example taken from vehicle manufacturing, namely the painting of a car. Independently of the concrete paint shop used, this manufacturing process takes the following steps: (1) car identification, (2) selection of the corresponding paint, (3) painting, and (4) drying. The car is identified by its vehicle identification number which is read using, for example, a bar code or an RFID tag. The vehicle identification number is used to query the ordered paint from the production database. Using this information, the car is painted and dried afterwards. The entire process is coordinated by a combination of IPC and PLC.

2.2. Web Services for Industrial Automation To bridge the gap between the business layer and the manufacturing layer, i.e. the service-oriented and non service-oriented world, we propose to wrap software at the manufacturing layer, more precisely PLC functions, as web services and expose them to the business layer. This approach leads to a seamless adoption of web services throughout the enterprise and renders a MES at the intermediate layer unnecessary. To realize our approach, several questions have to be answered: • How can web services be used to communicate with a PLC? • Which types of functions are offered by a PLC and which of these should be exposed as web services? • How can the time constraints of a PLC function be modeled within a web service? • How can the modeled time constraints be satisfied? Today’s PLCs normally do not offer enough computing power to run a conventional operating system like Linux or Microsoft Windows in combination with a web service engine (aka SOAP engine) like Apache Axis (http: //ws.apache.org/axis2/). Most PLCs only offer a rudimentary web server for monitoring purposes. Therefore, it is technically very challenging to communicate with a PLC via web service technology directly. To solve this problem, we propose to use the IPC as a facade to enrich the PLC with web service functionality, i.e. a function offered by a PLC is wrapped as a web service and exposed to the IPC. Wrapping every function offered by a PLC as a web service does not make sense. PLC functions can be distinguished in maintenance functions, control functions, and

Tool-Support Layer Real-time Service Layer Hardware Layer

monitoring functions. Maintenance functions are used to maintain the PLC itself, e.g. updating the firmware. These functions are of little interest to higher layers and therefore it is not necessary to wrap them as services. Monitoring functions are used to query the status of the PLC (e.g. uptime, firmware version, internal failures) and the status of the manufacturing process (e.g. already manufactured units, occurred exceptions and problems). These information are very important for higher layers and therefore should be wrapped as web services. Control functions implement logic to control a part of the production process. These functions can be distinguished in safetycritical and non safety-critical functions. For example, a safety-critical control function implements an emergency stop. These functions should not be wrapped as web services. A non safety-critical control function reads input data from a sensor or triggers an actuator. This functionality is wrapped as a web service and exposed to higher layers. Due to the fact that some functions offered by a PLC have to satisfy time constraints, it is important that the IPC is also able to guarantee these time constraints. More precisely, the operating system, the web service engine, and the programming language used at the IPC to implement the web services must be able to satisfy these time constraints. Since modern operating systems do not support realtime processing a priori, a real-time operating system (RTOS) has to be used to run the IPC. An RTOS typically deals with the scheduling of jobs with the aim of meeting their deadlines. Today’s widely-used web service engines do not support time constraints. Therefore, the design and implementation of a time-constrained web service engine are mandatory to realize our proposal. The implementation of web services can be based on an arbitrary time-constrained programming language, since interaction between web services is only based on their published interfaces.

Real-time Modeler

Real-time Repository

Real-time SOAP

Wizard Wizard Wizard

Flex-SwA

Real-time BPEL4WS

Time-Constrained Runtime Environment

IPC IPC IPC

PLC PLC PLC

Monitoring

Time-Constrained Time-Constrained Web Service Time-Constrained Web Service Web Service

Time-Constrained Time-Constrained BPEL4WS Workflow Time-Constrained BPEL4WS Workflow BPEL4WS Workflow

Manufacturing Manufacturing Device Manufacturing Device Device

Figure 3. Architecture of the Constrained Services framework.

Time-

This section outlines the architectural blueprint of the TiCS framework and focuses on the TiCS Wizards and the TiCS Real-time Repository. Additionally, it is discussed how real-time can be realized using Linux as the operating system and Java as the programming language.

The entire TiCS framework is set up on standardized automation hardware, i.e. Industrial PCs, Programmable Logic Controllers, and arbitrary manufacturing devices (e.g. industrial robots), to guarantee backward compatibility with existing automation solutions. The technical details of the automation hardware, e.g. hierarchical arrangement and wiring of the manufacturing devices, are hidden by the hardware layer. The real-time service layer contains all infrastructural components of the TiCS framework, such as the real-time SOAP and real-time BPEL4WS engines, several time-constrained web services and time-constrained BPEL4WS workflows, and the repository. Flex-SwA [6] permits the efficient transmission of binary data as input/return parameters of web services. Potential users of the TiCS framework are automation engineers who are domain experts but do not necessarily know web services. Therefore, exhaustive tool support is required to ease the implementation, composition, deployment, and publication of time-constrained web services and workflows and the monitoring of the entire TiCS framework. The tool-support layer offers these features by means of the real-time modeler, several wizards, and a monitoring component.

3.1. Architectural Blueprint The Time-Constrained Services (TiCS) framework is a full-fledged development environment for timeconstrained web services and consists of three functional layers – tool-support layer, real-time service layer, and hardware layer – which contain several components to meet the demands of a web service based automation infrastructure. Figure 3 outlines the architectural blueprint of the TiCS framework.

3.2. TiCS Wizards The development process of a (time-constrained) web service has several steps: (1) Service Implementation: An automation engineer starts by implementing a web service and describing its real-time properties, e.g. real-time domain (hard or soft), maximum execution time, or average execution time. (2) Service Deployment: After the service has been implemented, the service has to be deployed to one or mul-

3. The Time-Constrained Services (TiCS) Framework

tiple nodes. The deployment process requires in-depth knowledge of the deployment mechanism of the used web service engine. (3) Service Publishing: After the implementationdeployment-cycle, the service is available for (re-)use by the engineer or other automation engineers. To keep track of all available real-time services, a service repository which acts as a real-time service directory can be used. An interface is necessary to add/remove services to/from the repository. These tasks are supported by three different TiCS Wizards, which are implemented as Eclipse plug-ins, and ease the development process for automation engineers: (1) Real-time Service Creation Wizard: The implementation of time-constrained web services is supported by a wizard that helps the engineer to define a Java class with several methods. For each method, real-time properties can be defined, e.g. real-time domain (hard or soft), maximum execution time, or average execution time. These properties are added to the methods using annotations. Given this information, a class template is generated which easily can be completed by the automation engineer. During implementation, the automation engineer is supported in adding new operations, as shown in figure 4. (2) Real-time Service Deployment Wizard: After having implemented a time-constrained web service, the service has to be deployed to a web service engine. The deployment process requires detailed engine-specific knowledge, depending on the web service engine used. To ease the deployment process, the automation engineer is supported by a service deployment wizard. (3) Real-time Service Publishing Wizard: This wizard eases the publication of a time-constrained web service in a Real-time Repository. The automation engineer must define where to publish a time-constrained web service, i.e. the endpoint of a specific repository, and which services should be published. The target repository can be chosen from a predefined set of repositories, or a new repository can be specified enabling service grouping. 3.3. Real-time Repository The implementation of the TiCS Real-time Repository can be based on several technologies, e.g. UDDI (Universal Description, Discovery, and Integration). For simplicity, we have implemented the repository with plain web services. To publish and to look up time-constrained web services at the repository, the following operations are used: • publishRealtimeService – A new timeconstrained web service is written to the repository and can afterwards be looked up. • removeRealtimeService – An already published time-constrained web service is removed from the repository. All subsequent lookups for this service will fail.

Figure 4. Adding a new real-time operation to a time-constrained web service. Time-Constrained Web Service

1

n

n Real-time Repository

Name

Operation

Host

1

1

1

1

Name

Real-time Domain

Average Execution Time

Maximum Execution Time

Figure 5. Overview of the model describing a time-constrained web service.

• lookup – This command can be used to obtain all information published for a specific time-constrained web service. • lookupAll – This command returns a list of all published time-constrained web services. A time-constrained web service has a name, several operations, and knows the hosts where it is deployed to. Each operation is characterized by its name, a real-time domain (hard or soft), an average execution time, and a maximum execution time. Figure 5 shows the model describing a time-constrained web service. 3.4. Time-Constrained Web Services Since a time constraint is a meta-information for a web service, annotations are suitable for describing it. The following information is attached to a web service using annotations: the real-time domain of each operation

Listing 1. Annotation for an operation with hard real-time constraints. @TimeConstraintAnnotation( realtimeDomain = RealtimeDomain.HARD, maximumExecutionTime = 6.2, maximumExecutionTimeUnit = TimeConstraintUnit.MILLI_SEC, averageExecutionTime = 2.9, averageExecutionTimeUnit = TimeConstraintUnit.MILLI_SEC )

Listing 2. Annotation for an operation with soft real-time constraints. @TimeConstraintAnnotation( realtimeDomain = RealtimeDomain.SOFT, maximumExecutionTime = Double.POSITIVE_INFINITY, maximumExecutionTimeUnit = TimeConstraintUnit.MILLI_SEC, averageExecutionTime = 5.4, averageExecutionTimeUnit = TimeConstraintUnit.MILLI_SEC )

(HARD or SOFT), the maximum execution time, the average execution time, and the time unit used (e.g. microseconds (MICRO SEC), milliseconds (MILLI SEC), or seconds (SEC)). In the soft real-time domain, the maximum execution time is undefined and therefore set to Double.POSITIVE INFINITY. Listing 1 and 2 show examples of annotations for an operation with hard and an operation with soft real-time constraints. The annotation in listing 1 describes that the associated operation guarantees a maximum processing time of 6.2 milliseconds, the average execution only takes 2.9 milliseconds. The annotation in listing 2 describes an operation that has an average processing time of 5.4 milliseconds. There is no maximum execution time defined. 3.5. Real-time Linux Conventional Linux distributions (e.g. openSUSE, Fedora, or Ubuntu) do not support real-time processing. To avoid the use of a commercial real-time Linux distribution offered by several vendors (e.g. FSMLabs Hard Real-time Linux), we extended a Linux standard kernel (vanilla kernel) with the RT PREEMPT patch (http: //rt.wiki.kernel.org/), which equips a conventional Linux distribution with a completely preemptible kernel. A preemptible kernel guarantees a maximum interrupt latency, i.e. a maximum time to call an interrupt handler for an occurred interrupt, and therefore a maximum context switching time for threads (thread latency).

A maximum thread latency permits to estimate the maximum execution time of an application for a given payload. After successful installation of the preemptible kernel, a benchmark of the environment helps to determine the maximum thread latency. For comparability reasons, a standard benchmark like cyclic-test or preemption-test should be used. To guarantee that actually the maximum thread latency is measured, the system should be heavily utilized. A generator for artificial load is, for example, lookbusy or stress. We used an Intel Pentium 4 with 2.8GHz clock frequency and 1GB main memory for our prototypical implementation. We replaced the distribution kernel with a vanilla kernel v2.6.23.11 patched with the corresponding RT PREEMPT patch v2.6.23.11-rt14; lookbusy was used to generate 100% CPU utilization and cyclic-test was used to measure the thread latency. Our experimental setup offers a thread latency of 6µs which meets the demands of today’s automation systems. 3.6. Java for Real-time Processing The implementation of a time-constrained web service engine and time-constrained web services requires the use of a real-time enabled programming language. The Java programming language – initially designed and developed for the implementation of consumer electronics software and Web applications – nowadays enjoys great popularity in various domains. The proliferation and popularity of Java is mainly based on its virtual machine concept, comprehensive class library, semi-automatic memory management, inherent security model, and its extensive tool support. However, Java is not suitable to implement real-time systems, due to its built-in memory management functionality. Java uses a semi-automatic memory management approach, i.e. objects are allocated on demand using the new-operator and automatically deallocated. All objects created during program runtime using the newoperator are allocated on the heap. Once the objects are not needed anymore, they are deallocated by the Garbage Collector (GC). For this purpose, the GC searches for objects which are not further referenced and removes them from the heap. All referenced objects may still be used and remain on the heap. By allocating and deallocating objects, the heap becomes more and more fragmented during runtime. Hence, the GC has to defragment heap space to maximize the free memory area at the end of the heap. The GC in Java is realized as an independent thread with highest priority, which is automatically started at program start. Therefore, the GC thread is able to interrupt normal program execution arbitrarily. Unfortunately, the amount of time the GC thread operates is not deterministic, i.e. the programmer cannot anticipate how long the application will be interrupted. To use Java in real-time environments, fundamental extensions of memory management are needed. For this purpose, the Real-Time for Java Expert Group (https://

rtsj.dev.java.net/) has developed the Real-Time Specification for Java (RTSJ). RTSJ extends the Java language specification and the JVM specification to enable analysis, creation, execution and verification of threads which have to satisfy time constraints. To achieve real-time behavior, RTSJ introduces new thread classes: RealtimeThread and NoHeapRealtimeThread. RealtimeThread extends the standard Java Thread class and implements the Schedulable interface, which is also defined by RTSJ. The class name RealtimeThread is misleading since a RealtimeThread also has a lower priority than the GC thread. Thus, a RealtimeThread can be interrupted by the GC. The difference between a RealtimeThread and a conventional Thread is the possibility to assign SchedulingParameters and ReleaseParameters, which define how the RealtimeThread is executed. Objects of the NoHeapRealtimeThread class have a higher priority than the GC thread. Hence, a NoHeapRealtimeThread is able to interrupt the GC and is executed deterministically. To allow this, a NoHeapRealtimeThread does not use heap space, but the newly introduced ScopedMemory or ImmortalMemory. There are several vendors which offer RTSJ-compliant JVM implementations bundled with several tools for realtime application development. The (commercial) reference implementation comes from Sun Microsystems and is called Sun Java Real-Time System. With IBM WebSphere Real Time, IBM also offers an RTSJ compliant JVM implementation. We used the JamaicaVM offered by aicas for our prototypical implementation, which supports hard real-time execution and real-time garbage collection. Using a real-time GC, a distinction between realtime threads and non real-time threads is not necessary, since every thread is processed within a predefined time constraint.

4. Use Case This section describes a use case to get a better understanding where time-constrained web services are useful and how their implementation is simplified using the TiCS framework. The example comes from the vehicle manufacturing domain. Consider an enterprise which acts as a component supplier for another enterprise from the automotive sector. Since manufacturing at the automotive sector often relies on just-in-time production, it is necessary that components from all component suppliers are available in the right quantity at the right time. Otherwise, financial penalties may be the consequence. The whole production process at the component supplier has to be coordinated with the customer from the automotive sector. In this use case, the customer from the automotive sector requires a new component from the component supplier since the production of a new car is started. The

business layer of the component supplier takes this order and generates a production order for the manufacturing layer containing the required quantity, maximum production time, and quality. To realize this production order, automation engineers have to implement several control, monitoring, and maintenance functions at the PLCs. Subsequently, some of these functions are exposed using timeconstrained web services. We exemplify the application of the TiCS Wizards and the TiCS Real-time Repository by means of a monitoring function. The business layer needs up-to-date information about the production process, especially the number of already produced units to avoid underproduction. Providing this information is time critical, since it reflects the actual status of the production process. Therefore, an automation engineer has to develop a time-constrained web service. To perform this task, the engineer takes three steps. (1) After implementation of the monitoring function at the PLC, it is necessary to expose this function as a time-constrained web service. The Real-time Service Creation Wizard is used to create a class template containing a method template queryProducedUnits and to define the real-time properties for this method, e.g. the maximum execution time. The real-time properties depend on the concrete implementation of the function at the PLC and its cyclic time, i.e. the time required to iterate over this function. The automation engineer has to implement the method template, i.e. the corresponding function at the PLC is called. (2) The new time-constrained web service has to be deployed to the IPC interconnected with the PLC. Service deployment is a very challenging task since it heavily depends on the web service engine. Therefore, the automation engineer uses the Real-time Service Deployment Wizard to deploy the new service to the IPC. The wizard hides all the unnecessary details from the automation engineer. (3) From now on, it is possible to invoke the new timeconstrained web service from the business layer, provided that the deployment endpoint is known. To publish this endpoint, the automation engineer uses the Real-time Service Publishing Wizard to interact with the TiCS Realtime Repository. Internally, the Real-time Service Publishing Wizard calls the publishRealtimeService command at the repository.

5. Related Work The SIRENA project [7] – part of the ITEA research program – is aimed at the development of a service infrastructure for real-time embedded networked applications. SIRENA envisions a seamless use of serviceoriented architectures within holonic industrial automation and identifies resulting business advantages. Unfortunately, SIRENA presents no realization details. Gilart-Iglesias et al. [3, 4] present a normalization process of industrial machinery which is called Industrial

Machine as a Service (IMaaS) which enables a seamless service-oriented integration of machines in the IT infrastructure. Even though IMaaS is similar to our approach, no solution to guarantee real-time processing and no tool support is presented. Delamer et al. [2] examine the use of event- and service-oriented architectures at the device level. Furthermore, semantic web services are investigated, which enables automatic service selection. This approach is very interesting, but the specific time requirements of the manufacturing layer are not taken into account. Kalogeras et al. [8] present a web service based system architecture for the vertical integration within industrial enterprises. This architecture completely ignores the specific real-time requirements within the manufacturing layer and tool support for automation engineers. Thus, our proposal can be used as a technical foundation for this architecture. There exist several programming languages for the formal description of the behavior of safety- and time-critical applications, e.g. Timber [1] and Hume [5]. Hume consists of three different layers: expression layer, coordination layer, and declaration layer. The expression layer is a functional programming language for describing processes and offers bounded time and space behavior. The coordination layer is a finite state programming language which describes the interaction of processes. The declaration layer is used to define functions, values, exceptions, etc. All three layers permit to infer the time behavior of the underlying application. Timber is an imperative object-oriented, concurrent, and purely functional programming language and permits the analysis of the timing behavior of an application. Timber offers monadic constructs to define hard real-time properties. Both languages offer interesting approaches for future versions of the TiCS framework to automatically infer the time behavior of a system.

6. Conclusions The increasing adoption of service-oriented architectures, especially web services, promises to abolish the heterogeneity of intra- and inter-enterprise communication and leads to vertical and horizontal integration. Unfortunately, the adoption of web services throughout the business, intermediate, and manufacturing layer of an industrial enterprise has three main difficulties: (1) hardand software at the manufacturing layer is less powerful than hard- and software on the other layers, (2) automation engineers who maintain the manufacturing layer often have less experience in the development and deployment of web services, and (3) some web services have to satisfy time constraints given by the overall business process. To solve these problems, we presented how Industrial PCs (IPCs) and Programmable Logic Controllers (PLCs) can be combined to expose PLC functions via the IPC as web services. Since some functions of the PLC are time-

constrained, it is important that the IPC satisfies these time constraints, too. Therefore, we have shown how a fullfledged, time-constrained web service stack at the IPC can be realized. The main idea of our approach is the use of standardized hard- and software only, which eases interoperability and adaptability. Furthermore, we presented the Time-Constrained Service (TiCS) framework, especially the TiCS Wizards and the TiCS Real-time Repository which empowers automation engineers to easily develop, deploy, and publish web services with time constraints. The usage of TiCS was exemplified with a use case from the automotive sector. Future work will focus on the development of a timeconstrained web service engine, which allows the deployment and invocation of web services under real-time constraints. Furthermore, we will evaluate the performance of this web service engine. Finally, we plan to evaluate our approach in a real-world application scenario with a partner from the automotive supplier industry.

References [1] A. P. Black, M. Carlsson, M. P. Jones, R. Kieburtz, and J. Nordlander. Timber: A Programming Language for RealTime Embedded Systems. Technical report, Oregon Health & Science University, 2002. [2] I. M. Delamer and J. L. M. Lastra. Loosely-Coupled Automation Systems Using Device-Level SOA. In Proceedings of the IEEE International Conference on Industrial Informatics (INDIN), pages 743–748, 2007. [3] V. Gilart-Iglesias, F. Macia-Perez, D. Marcos-Jorquera, and F. J. Mora-Gimeno. Industrial Machines as a Service: Modelling Industrial Machinery Processes. In Proceedings of the IEEE International Conference on Industrial Informatics (INDIN), pages 737–742, 2007. [4] V. Gilart-Iglesias, F. Macia-Perez, F. Mora-Gimeno, and J. Berna-Martinez. Normalization of Industrial Machinery with Embedded Devices and SOA. In Proceedings of the IEEE Conference on Emerging Technologies and Factory Automation (ETFA), pages 173–180, 2006. [5] K. Hammond. Hume: A Bounded Time Concurrent Language. In Proceedings of the 7th IEEE International Conference on Electronics, Circuits and Systems (ICECS), pages 407–411, 2000. [6] S. Heinzl, M. Mathes, T. Friese, M. Smith, and B. Freisleben. Flex-SwA: Flexible Exchange of Binary Data Based on SOAP Messages with Attachments . In Proceedings of the IEEE International Conference on Web Services (ICWS), pages 3–10, 2006. [7] F. Jammes and H. Smit. Service-Oriented Paradigms in Industrial Automation. IEEE Transactions on Industrial Informatics, 1:62–69, 2005. [8] A. Kalogeras, J. Gialelis, C. Alexakos, M. Georgoudakis, and S. Koubias. Vertical Integration of Enterprise Industrial Systems Utilizing Web Services. In Proceedings of the IEEE International Workshop on Factory Communication Systems (WFCS), pages 187–192, 2004. [9] J. A. Stankovic. Misconceptions about Real-Time Computing: A Serious Problem for Next-Generation Systems. Computer, 21:10–19, 1988.