The goals of PROMISE fall into the categories of technical, business, and .... information systems, which can then be used to support business decisions. Using.
PROMISE: Product Lifecycle Management and Information Tracking using Smart Embedded Systems Jürgen Anke, Bernhard Wolf, Gregor Hackenbroich, Hong-Hai Do, Mario Neugebauer, Anja Klein Abstract: Product Lifecycle Management (PLM) processes can be greatly improved and extended if more information on the product and its use is available during the various lifecycle phases. The PROMISE project aims to close the information loop by employing product embedded information devices (PEIDs) in products. In this chapter, we present the goals and application scenarios of the project with special focus on the middleware, which enables the communication between PEIDs and enterprise applications. Furthermore, we give details on the design and implementation of the middleware as well as the role Universal Plug and Play (UPnP) as device-level protocol. Keywords: System Architecture, Middleware, Case Study
INTRODUCTION The PROMISE project (PROMISE consortium, 2006) aims at improving business processes of Product Lifecycle Management (PLM) by using the information loop across the various stages in a products lifecycle, from Beginning-of-Life (Design, Production) to Middle-of-Life (Use, Maintenance) and End-of-Life (Recycling, Disposal). The technological approach of the project is to use smart networked devices that are embedded into products to gather data on the product’s status, properties, and working environment. The data is then made available to backend systems to perform data analysis for decision support. Moreover, the gain information is exchanged between the various interested parties, e.g. manufacturer, customers, service and recycling companies. The vision of closing the information loop for PLM has attracted the interest of a number of large companies, like Infineon (Germany), Bombardier Transportation (France), Fiat/Iveco (Italy), and Caterpillar (France/USA), besides SAP, to take part in the project. This emphasizes the relevance of the idea and also the commitment of industry in realizing it. In particular, Infineon develops the hardware for PEIDs (product embedded information devices) to be installed in physical products.
PROJECT GOALS The goals of PROMISE fall into the categories of technical, business, and research goals:
Technical Goals
Product Embedded Information Devices (PEIDs): Suitable PEIDs have to be developed with turn products into smart items. PEIDs will provide data about the product to external applications. Using PEIDs will enable automatic data
acquisition of high accuracy, which is less error-prone and more efficient than manual collection and entry of the data. Integration of PEIDs with backend systems: To enable the communication between PEIDs and backend applications, a middleware providing abstraction from device-level protocols and data transformation is required. Product Data and Knowledge Management (PDKM): Product-related data from PEIDs, field databases, and other sources have to be integrated to allow for sophisticated data analysis. Decision Support: Data from the PDKM has to be analyzed to transform the data into actionable knowledge for PLM decision support. Cross-company information flows: A major hurdle for today’s PLM applications is the inaccessibility of product-related data in other organizations. To overcome this, methods and software that allows sharing of data, information and knowledge among certified actors of the system has to be developed.
Business Goals
Enable new business models: Using technology developed in PROMISE, new business models, e.g. in the areas of product service and recycling, shall be developed to increase the economic impact of results from applied research. Improve existing business processes: Business processes related to PLM shall be improved and extended, e.g. by achieving lower operational cost, better quality and safety, reduction of errors, and better informed decisions.
Research Goals
Generic PLM models: The consolidated requirements of many PLM application scenarios are to be integrated into domain-specific and generic models of PLM information flow and PLM workflow. Information and Knowledge Management Methodologies: To turn the collected product data into useful knowledge for decision support, methods and concepts for information enrichment and transformation of information into knowledge have to be developed.
INNOVATIONS IN PLM BUSINESS PROCESSES In the following, three application scenarios are presented, to show how PROMISE technology can be applied for PLM business process in Beginning-of-Life (BOL), Middle-of-Life (MOL), and End-of-Life (EOL)
Improved Product Design - Bombardier (BOL) Bombardier is a provider of rail equipment and servicing. Based on a component platform, Bombardier designs and produces a large number (over 400) of different locomotives. Applying the PROMISE idea, Bombardier aims at closing the information loop between the experience in service (field data) and the knowledge needed in order to develop improved locomotives for specific criteria, such as, Design for Reliability, Availability & Maintainability / Life Cycle Costs, Product Safety, Environment, etc. For that, field data is recorded on the locomotives and transferred to a field database using GSM (Global System for Mobile Communication). The data is then analyzed for information on the performance of components compared to their expected behavior. Based on that, the engineers can evaluate the suitability of their designs and improve them accordingly.
Flexible Maintenance Planning - Fiat (MOL) Fiat focuses on predictive maintenance of trucks. To improve the effectiveness of fleet management, FIAT seeks new ways to better understand the product usage and the mission profile of Iveco commercial vehicles. The objective is to provide customers with flexible maintenance planning, which is based on the actual degradation of vehicle components instead of fixed intervals. With this approach, costly breakdowns are avoided, while preventing the replacement of parts which are still in good condition. The correct timing for maintenance is determined by measuring the wearout of selected critical components with sensors that are integrated into the vehicle. Furthermore, the mission profiles of trucks are determined, in order to predict the wear-out for components depending on the respective mission profile. For each truck, the output of the decision support system is a calendar containing the time and the type of planned interventions. The maintenance crew is provided with a consolidated view on all interventions of the fleet.
Effective Recycling - Caterpillar (EOL) Caterpillar is a manufacturer of construction and mining equipment. Using PROMISE technology, Caterpillar aims to support decommissioning of heavy-load machinery at the end of its life. More specifically, the value of the vehicle’s components has to be evaluated to identify the ones that can be reused. Previously, the end of life decisionmaking was based on inspection in order to determine whether a component can be remanufactured. Now, a PEID monitors the product’s status and systematically collects data during the machines operation. Using a smart item middleware, this data can be accessed from the PEID and stored in a database. When the machine is decommissioned, the data associated with the built-in parts is retrieved from the databases and serves as input to a decision support system (DSS), where it is combined with data on economic demand. Thus, the appropriate handling of the various components is determined, e.g. deciding whether to dispose, recycle, reuse or remanufacture components in order to increase the re-use of components.
TECHNICAL SOLUTION OVERVIEW Overall PROMISE Architecture The technical solution of PROMISE consists of different layers, which are consolidated into the overall PROMISE architecture (see Figure 1).
Figure 1: PROMISE Architecture
Business processes of various application areas are supported by applications for decision support and product data and knowledge management (PDKM). These applications access PEID data through a middleware, which provides functionality for reading and writing of PEID data, as well as notifications on data updates, and PEID management. On the PEID level, mechanisms for detection of devices and invocation of services are offered.
Brief Overview of the PROMISE Middleware A key part of the PROMISE architecture is the middleware, which was co-developed by SAP. Its purpose is to connect PEIDs with backend applications to facilitate data exchange between them (see Figure 2). One of the main challenges in the design of the middleware was to support mobility of products. As products can be mobile (e.g. trucks, locomotives), they might not be permanently connected to the network. To handle this, the communication between backend applications has to be asynchronous. Furthermore, the presence of devices has to be detected automatically, in order to trigger the execution of pending requests.
Figure 2: Logical components of the PROMISE middleware
The middleware is divided into three logical layers, which are described here briefly:
Device Handling Layer: The DHL provides mechanisms for device discovery and invocation of services on the PEID to access data. In the PROMISE middleware, this was achieved by using Universal Plug and Play (UPnP Forum, 2006). All PEIDs implement a unified UPnP interface called “Core PAC” (Core PEID Access Container). When a PEID is detected, the DHL connects to it and sends a notification to upper layers of the middleware. Additionally, it translates incoming requests into UPnP services invocations to read or write PEID data.
Request Handling Layer: The RHL provides Web Services to interface with backend applications, which can place requests for PEID data at the RHL. If the required PEID is currently connected, the request is directly forwarded to the DHL. Otherwise, it is buffered until a connection notification is received from the DHL, which triggers the forwarding of the request. In a large scale deployment, a RHL node can be connected to multiple DHL nodes, which can be installed in different physical locations to provide PEID connectivity.
Inter-System Communication: To provide cross-organizational communication, the ISC was developed. It is an optional part of the middleware stack for scenarios where external parties are to access PEID data. In these scenarios, each organisation has at least one Inter-System Communication (ISC) node installed, which then connects to other ISC nodes in a peer-to-peer fashion. Backend applications place their request at an ISC node, which then forwards the request to the correct RHL, PDKM or third-party system. Therewith, companies can gather product-related information from other organizations.
IMPLEMENTATION We have implemented the lower layers (RHL and DHL) of the middleware, which was introduced in the previous section. Figure 3 shows the detailed design of these two layers. Here, we give some details on the chosen technologies and elaborate on some of the developed notification mechanisms.
Figure 3: Detailed design of RHL and DHL layers
The Connection Manager in the DHL implements a UPnP Control Point (Institute of Information Science and Technologies, 2006; Konno, 2006) that can read and write information on PEIDs once they have been discovered in the network. The DHL is realized as an application consisting of a set of bundles running on an OSGi (OSGi Alliance, 2007) service platform, in our case the open source distribution Oscar (Hall, 2006). The RHL is implemented as a Java 2 Enterprise Edition (J2EE) application, with its functional components being Enterprise Java Beans (EJB) (SUN, 2006). For deployment, a J2EE 1.3 (SUN, 2002) compliant Application Server (SAP Help, 2007) was used. Container-managed entity beans are implemented to represent the business objects such as targetIds and infoItemIds. They are mapped to tables, which are then automatically deployed on the server. Web services to be invoked from backend applications are also automatically generated from the beans. A timing service was required for the management of subscriptions to RHL requests. To compensate for the lack of an EJB Timer service in J2EE 1.3, the Open Symphony Quartz (Open Symphony, 2006) was used as a powerful library for scheduling. Communication between RHL and DHL is established using Java Messaging Service (JMS) which provides reliable asynchronous messaging. The JMS Provider manages three queues to exchange messages between the two layers. A request queue and a response queue are dedicated to receive requests from the backend applications via the RHL and the corresponding responses from the DHL, respectively. A third queue is used for the delivery of notification messages for discovered PEIDs as well as metadata about those PEIDs.
For the processing of messages on the DHL, a JMS MessageListener is implemented to listen on the request queue for incoming requests. To enable the DHL to retrieve the factories required for JMS communication, a J2EE client library (Opgenorth, 2005) has been included as an application bundle. On the RHL, the Request Processor contains Message-Driven Beans (MDB), listening on the response queue and notification queue to process the messages which are received on it. When a device is discovered by the Connection Manager and permitted to connect by the Device Manager, a JMS notification message with the PEID and respective metadata is sent to the notification queue. The dedicated MDB within the Request Processor then performs the necessary processing to check for pending requests for that PEID. If there are requests buffered, they are sent via the request queue to the DHL as JMS messages. After performing the required operation (read/write), the result for each request is then sent back via the response queue to the RHL. The result messages are handled by the mentioned MDB, which places the results in a buffer to be retrieved by the backend applications through a Web Service interface. Incoming requests are forwarded to the request queue until the RHL gets notified of the disconnection of the PEID. When a backend application has placed a subscription on the Request Handler, a trigger is created with a subscription interval and the subscription is then scheduled as a Quartz job. Whenever the RHL is notified of the disconnection of a PEID, all the subscriptions on that PEID are paused. When the PEID connects again, all the subscriptions placed on it are resumed. Whenever it is activated, the scheduled job sends a request according to the given interval, which is then handled as described above.
BENEFITS AND LIMITATIONS The presented system allows backend systems to acquire data from product embedded information systems, which can then be used to support business decisions. Using UPnP as standard technology for detection and invocation of services as well as a common data access scheme (“InfoItems” and their IDs) an abstraction from concrete products can be achieved. Thus, the middleware enables reading and writing of PEID data for a large number of heterogeneous products. One of the major drawbacks is that all products not only have to be a UPnP compatible, but also implement the UPnP interface, which was defined in the PROMISE project. It remains to be seen, to which extend this interface is used in realworld applications. However, our middleware architecture is designed with abstraction as a major goal. Therefore, it is also possible to support other protocols and interfaces by implementing a designated DHL instances for that. Such an extension would not affect backend applications and the RHL. Additionally, we have not yet conducted a thorough analysis of performance and scalability for the middleware.
SUMMARY The PROMISE project shows how smart embedded systems can be employed for future generations of product lifecycle management applications. Real-world application scenarios do not only give a proof-of-concept but also show the variety of different business problems that can be addressed with the help of PROMISE technology. Transparency about product data and its exchange across company
boundaries are the main drivers for these new capabilities. However, it also highlights the importance of standards for product identification, detection and data exchange. These standards have to be not only suitable for a technical problem, but also accepted in the industry to enable interoperability.
REFERENCES PROMISE consortium. “Product Lifecycle Management and Information Tracking using Smart Embedded Systems”, Project website, Retrieved January 3, 2007, from http://www.promise.no/. UPnP Forum. Retrieved September 14, 2006, from http://www.upnp.org. Satoshi Konno. “CyberLink for Java”, Retrieved December 10, 2006, from http://www.cybergarage.org/net/upnp/java/index.html. Jürgen Opgenorth (October 2005). “SAP J2EE Migration Guide”, SAP Developer Network (SDN). Institute of Information Science and Technologies (ISTI) Pisa. Domoware, Retrieved November 22, 2006, from http://domoware.isti.cnr.it/. Open Symphony. Quartz Enterprise Job Scheduler Homepage, Retrieved December 2, 2006, from http://www.opensymphony.com/quartz/. OSGi Alliance. Open Services Gateway Initiative, Retrieved January 21, 2007, from http://www.osgi.org. Richard S. Hall, “Oscar – An OSGi framework implementation”, Retrieved September 5, 2006, from http://oscar.objectweb.org. SAP Help. “Architecture of the SAP Web Application Server”, Retrieved January 21, 2007, from http://help.sap.com/saphelp_nw04/helpdata/en/84/54953fc405330ee10000000a11408 4/content.htm. SUN (2005). “Enterprise JavaBeans Technology”, Retrieved October 20, 2006, from http://www.java.sun.com/products/ejb/. SUN (2002). “Java 2 Platform, Enterprise Edition (J2EE) 1.3”, Retrieved January 29, 2007, from http://java.sun.com/j2ee/1.3/index.jsp.
