The PLANTCockpit project (260018) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7). ThisdocumentdoesnotrepresenttheopinionoftheEuropean Community, and the European Community is not responsible for any use that might be made of its content. ProgrammeFactories of the Future PPP Strategic ObjectiveICT-2010-10 Smart Factories: ICT for agile and environmentally friendly manufacturing Project TitleProduction Logistics And Sustainability Cockpit AcronymPLANTCockpit Project #260018 TECHNICAL REPORT - EXTERNAL INTERFACE SPECIFICATION, FIRST DRAFT Work PackageWP4 System Interfaces and Integration Logic Lead PartnerTUD Contributing Partner(s)SAP, TECNALIA, TUT, ICONICS, INTEL Security ClassificationPublic Date13/04/2012 Version1.0 Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpitii Table of Contents 1EXECUTIVE SUMMARY ............................................................................................ 1 2INTRODUCTION ........................................................................................................ 2 3PLANTCOCKPIT SYSTEM CONNECTOR LAYER ................................................... 3 4ADAPTERS FOR PLANTCOCKPIT........................................................................... 5 4.1ADAPTER TYPES FOR PLANTCOCKPIT................................................................................... 6 4.1.1SAP ERP / BAPI............................................................................................................. 6 4.1.2Business Objects............................................................................................................ 7 4.1.3SAP BW / BEx Queries................................................................................................... 9 4.1.4Web Service ................................................................................................................. 12 4.1.5DPWS .......................................................................................................................... 13 4.1.6MS Excel ...................................................................................................................... 18 4.1.7MS Project ................................................................................................................... 19 4.1.8OPC Unified Architecture .............................................................................................. 21 4.1.9SQL.............................................................................................................................. 23 4.2ADAPTER ROLES ................................................................................................................ 26 4.3NON-FUNCTIONAL PROPERTIES OF ADAPTERS ....................................................................... 26 5ABSTRACT INTERFACE SPECIFICATION OF THE PLANTCOCKPIT ADAPTERS 28 6ABBREVIATIONS .................................................................................................... 32 7CONCLUSION ......................................................................................................... 34 8REFERENCES ......................................................................................................... 35 9ANNEX ..................................................................................................................... 36 9.1INTERFACE DEFINITION LANGUAGES ..................................................................................... 36 9.1.1OMG IDL ...................................................................................................................... 36 9.1.2Microsoft Interface Definition Language (MIDL) ............................................................ 37 9.1.3XPIDL .......................................................................................................................... 37 9.1.4Apache Thrift ................................................................................................................ 37 9.1.5Apache Etch ................................................................................................................. 38 9.1.6Apache Avro................................................................................................................. 38 9.1.7WSDL .......................................................................................................................... 39 9.1.8Interface Description Language (IDL)............................................................................ 41 9.2COMPARISON TABLE OF INTERFACE DEFINITION LANGUAGES .................................................. 42 Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpitiii Table of Figures Figure 1: The System Connector Layer of PLANTCockpit .................................................................. 3 Figure 2 Adapters as function blocks in the PLANTCockpit Function Engine ...................................... 4 Figure 3 Adapter Types and Adapter Roles in PLANTCockpit ............................................................ 5 Figure 4: Layers of an SAP Business Object comp. (SAP, 2012)........................................................ 7 Figure 5: Analyzing info cubes comp. (SAP, 2012) ........................................................................... 11 Figure 6 SOAP Envelope (Mitra & Lafon, 2007) ............................................................................... 13 Figure 7: Arrangement of DPWS Clients, Devices, and Services (Lastra & Delamer, 2006) .............. 14 Figure 8: Network Protocols and Specifications included in the Devices Profile for Web Services (Microsoft, 2009) ............................................................................................................................. 15 Figure 9: OPC UA Stacked Architecture........................................................................................... 23 Figure 10: The PL/SQL Engine and the Oracle Database Server (Oracle, 2005) .............................. 25 Figure 11 PLANTCockpit adapters as function blocks ...................................................................... 28 Figure 12 The interfaces of the PLANTCockpit adapter .................................................................... 29 Figure 13: WSDL 1.1 and 2.0 Document Structure(Cristcost, 2007) ............................................... 40 Table of Tables Table 1: Specifications in the Devices Profile for Web Services........................................................ 15 Table 4 IIdentification interface descriptions ..................................................................................... 29 Table 5 IConfiguration interface descriptions.................................................................................... 30 Table 6 IRuntimeData interface description ...................................................................................... 31 Table 7 Abbreviations ...................................................................................................................... 32 Table 8: Structure of WSDL 1.1 and WSDL 2.0 files......................................................................... 40 Table 9 Comparison of Interface definition languages ...................................................................... 43 Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit1 1Executive Summary ThisdocumentdescribesthefirstdraftoftheexternalinterfacesofPLANTCockpit.The conceptofadaptersisintroduced.Targettechnologiesforexternalsystemsandresulting interfacestothesesystemsareidentified.Theinterfacestothetargettechnologiesare definedastheadapterstype,whereastheinterfaceexposedinsidethePLANTCockpit system is assigned an adapter role. A set of interfaces of the adapters of PLANTCockpit is given.Theseinterfacesaretobeusedinanupcomingreferenceimplementationofa PLANTCockpitadapter.Theannexcontainsananalysisofinterfacedefinitionlanguages and an example on mapping of external data sources to PLANTCockpit data structures. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit2 2Introducti on PLANTCockpitaimsatprovidingshopfloorawarenessandvisibilityfortheEuropean manufacturingandprocessindustry.Theprojectwillnotonlyprovidestrongusecases whichillustratethisgoalthroughtheparticipatingindustrypartners,itwillalsoshowa genericapproachforusageinEuropeanindustries.Itisexpectedthattheprojectwill leveragenewapproachesandinnovationsfordataaccessibilityandvisualisationinthe industrial domain. When shop floor and production logistics information should be visualised, it first needs to be made available. Industrial communication systems are still rife with heterogeneous, insular data processing solutions. However, the demand for lean, high performance, high availability production processes and the advent of classic IT technologies on shop floors has led to an abundanceofinterfaces.Whilstthisabundanceispreferabletotheinsularsituation engineers were faced with before it does have its own complications however. An abundance of interfaces means that integration efforts become more complicated to the square. State of the art reflects the fact that interface integration is a time-consuming and work-intensiveprocess.Thismeanswheneveranenduserofindustrialcommunication systemswantstointegrateasolutionwithanewinterface,hehastocustomizeits integrationwithallhisothersystems.Wheninformationfrommanydifferentsystemsis calledfor,asitisinPLANTCockpit,anefforttomakethissituationmanageableisof undisputed worth. ThePLANTCockpitdeliverableD3.1hasaddressedthechallengethePLANTCockpit architecturefaceswhenconnectingtoothersystemsbyintroducinganexternalsystem connector layer. Work package 4 of the project is tasked with filling out this layer, providing anindepthdescriptionofcomponentsalongwithprototypicalimplementations.Thefirst obstacle tackled when connecting external systems to the PLANTCockpit are the interfaces provided on both ends. This deliverable discusses the interfaces encountered and offers a specification. Based on this specification, implementation for data adapters for the prototype workpackagescanbestarted.Further efforts areneededinordertomakesurethatnot merelydata,butinformationisproperlyprocessedfromtheexternalsystemsintothe PLANTCockpit system. The goal of minimising the manual configuration effort for this task will be handled in D4.2 mapping and transformation framework, accompanied by an update onthedefinitionsprovidedin thisdeliverable tobefoundinD4.3Finalexternalinterface specification. For reference, a table of abbreviations is given in Annex 6. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit3 3PLANTCockpit System Connector Layer TheoverallPLANTCockpitarchitecturehasbeendescribedinthepreviouslysubmitted deliverable document D3.1. However, some aspects of the System Connector Layer and the decisionsleadingtoitsdesignwillbeofrelevance forthisdocumentandareelaborated here. Inside the PLANTCockpit architecture, a whole layer of components is dedicated to providing connectivitytothevariousexternalsystemsthatPLANTCockpitneedstoaccess.This SystemConnectorLayerhasthreetypesofcomponentsdefined.Thelayoutofthese components, which has been described in D3.1, is illustrated in Figure 1. Figure 1: The System Connector Layer of PLANTCockpi t TheMappingandTransformationcomponentisnotfocussedoninthisdocument.The reasonforthisisthatthiscomponentwillhandlesemanticmappinginPLANTCockpit,a topicthatwill becoveredinmoredepthinD4.2.Itissuffice tosayatthis pointthatthe MappingandTransformationcomponentwillprovideaninterfacefortheAdapters,with which mapping and data conversion services can be requested. TheAdaptersandtheAdapterManager,however,arethetechnicalimplementationof external interfaces for PLANTCockpit. Their definition is the main scope of this deliverable. The Adapter Manager is an arbitrator of Adapter life cycles and interactions. It shall manage theinstallationconfigurationofadapters,aswellasthesystemconfigurationoftheir instances. A change to the original architecture as defined in D3.1 is the following. Adapters are not separated from function blocks in their implementation. To simplify the architecture andtoaddresstheuniformityofmessageexchangebetweencomponents,adaptersare designed as function blocks, which follow in principle the same internal interfaces that are defined for the contents of the PLANTCockpit Function Engine (see D3.1 for details on this Engine). This makes the integration ofadapters into a function block network as easy as possible. The adapter acts as just another function block. Adapters are designed to provide the interfaces to the external systems. Thus, they cover specificunderlyinginterfacesandservicesandprovidetheseinterfacesfortheoverall PLANTCockpit approach. Compared to the function blocks used in the Function Engine, the adapters in the System Connector Layer can be seen as service interface function blocks. It is obvious that their internal details and structure need to follow the specific requirements of theexternalsystems.Dependingontheseimplementationdetails,differentadaptertypes can be defined, even for the same external system, however all the interfaces the adapter types provide to the Function Block Engine remain uniform in structure. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit4 Figure 2 Adapters as function blocks in the PLANTCockpit Function Engine The homogeneity of function blocks and adapters when running in the Function Engine is illustrated in Figure 2. Due to the different types and roles that adapters embody, however, additionalinformationisnecessarythatisspecifictoeachoftheadapters.TheAdapter Manager is dedicated to this adapter-specific information. The task of the Adapter Manager is to marshal and make discoverable the different adapters and their associated information. The following chapter details the adapters, their interactions with the rest of the framework, as well as how they are meant to connect to external systems. The main idea here is that each adapter is specific to one target technology. That way, the specifics of each technology canbeaddressed.Thedisadvantageofthisis,ofcourse,thatanadapterneedstobe writtenspecifictoeachtargetexternaltechnology.This,however,canbeturnedintoan advantage, since it makes the PLANTCockpit framework flexible and expandable.In order to keep the efforts involved manageable, relationships between the different adapter types and roles are elaborated and illustrated. It is shown how the introduction of adapter types and adapter roles allows one to hide connection details of the external systems from theusersofPLANTCockpit.Thesesimilaritiesaretobeusedinlaterstepsofthiswork package, where configuration efforts are to be managed. The similarities are also used for mapping and transformation. In chapter 5 the interfaces of the adapters are elaborated in more detail. In Annex 9.1 a state of the art analysis of interface specification options is given. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit5 4Adapters for PLANTCockpit Ashasbeendiscussed,adaptersareakeycomponentforconnectingPLANTCockpitto external data sources. This section describes the requirements adapters for PLANTCockpit havetofulfil.TheadaptersofPLANTCockpitaremeanttotieintotheFunctionEngine, exposingafunctionblockinterfacetowardstheframework.Towardsexternalsystems, however,theyneedadditionalproperties.Inordertoaddressdifferentexternalsystems, sometimesdifferentadaptersareneeded.Theseadaptersneedtoadapttothespecific requirements of each external system. When trying to classify the adapters, the results of the requirements analysis as documented inD2.3.1provideasolidbasisofusecasedriventargetsfortheintegrationofexternal systems.Itbecameapparentthatfortheusecasepartners,thetechnologytheexternal system is based on has a secondary focus. For the use cases, the role the system is fulfilling intheoverallproductionprocessismuchmoreimportantthanthetechnicalaspects. Regarding this situation, two important properties of adapters require to be defined. One is theadaptertype.Technicalaspects forconnectingtoanexternalsystemdependonthe adapter type, so that the types are differentiated by the addressed technology. The other is theadapterrole.Thedataprovidedbyanexternalsystemisimportantfortheusagein PLANTCockpit for a certain reason. This reason can be conveyed as the role of the adapter. Figure 3 Adapter Types and Adapter Rol es in PLANTCockpit The relationship of adapter types and adapter roles can be seen in Figure 3. The adapter type exposes an external interface towards a system outside of PLANTCockpit, the adapter role is the deciding factor on how the internal interface of an adapter is used. Other function blocks see the adapter only as another function block according to its role. Adapter types can be easily show-cased by describing the relevant interface technologies. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit6 Section 4.1 contains the description of all technologies and interfaces to external systems that will be addressed in PLANTCockpit. This covers mostly use-case-driven approaches, but the consortium agreed to also include OPC Unified Architecture (OPC UA) into the list. ThereasonforthisisthatOPCUAisakeytechnologywhenconnectingtoshopfloor systems. Giving proof that PLANTCockpit can be used with this technology as well as the use case technologies is a convincing validation of the overall solution. AdapterroleswillberepresentedbyPLANTCockpit-internalelements.Forexample,a production order extracted from an external system will be mapped onto a production order element inside the PLANTCockpit KPI calculation. Because the role of an adapter carries a lot of semantics, it is a non-trivial task to assign them. Adapter roles are described in-depth in section 4.2. 4.1Adapter types for PLANTCockpit Thissectiondiscussestheadaptertypesthatareplannedtobeimplementedinthe PLANTCockpit project. This is done by explaining the target technologies for the adapters. The main focuses in the explanations are interfaces that can be used to access information stored in the respective technologies. Twoimportanttechnologieshavenotbeenidentifiedastargettechnologiesfor PLANTCockpit, so they will not be discussed in detail. However, a short comment about both sensor networks as well as MTConnect is needed. Sensor networks are an important area of researchforindustrialapplicationsofinformationtechnology.Whilethisimportanceis undisputed, none of the use cases of PLANTCockpit calls for a direct access to a sensor network. This does not mean that PLANTCockpit is not for sensor networks. The adapter approachisdesignedinawaythatallowsthewritingofasensornetworkadapterand therebyaddressingthisimportanttechnology.Thedecisiontonotdosointheprojectis based solely on a focus on the use-case-relevant technologies and OPC as aan example proof-of-concept going beyond that. A similar assessment has to be given for MTConnect. The use cases did not call for it, so an MTConnect adapter will not be written in the project. However, the concept expressely allows for an MTConnect adapter to be written. The usage of XML on both ends will make the implementation of this adapter manageable for interested parties.Despitebeingopenforthesetechnologies,onlythosetechnologiestobe implemented in the project are explained in more detail here. 4.1.1SAP ERP / BAPI Tomanageanenterpriseandmonitor orexecutebusinessprocesses,softwaresolutions called Enterprise Resource Planning (ERP) systems exist. They can be used for nearly all enterpriseareas,fororganizationalormanagementtasks,likecontrolling,warehousing, retailing,productionplanning,finance,logistics,sales,disposition,accountingorpersonal management.Different ERP systems can be integrated with each other via the internet to enable cross-company processes, fasten to tasks and reduce costs. In such supply chains customers and suppliers are integrated (ITWissen, itwissen.info 2012). The SAP ERP system is the Enterprise Resource Planning solution offered by SAP. In an SAPERPsystemalldataisbasedonBusinessObjects(BOs).SAPBOscapsulatethe business data and processes stored in an SAP system. Therefore they hide the structure and implementation details of the underlying data (SAP, 2012). Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit7 4.1.2Business Objects Data stored in an SAP business system is modeled as Business Objects (BOs). BOs can be real world objects like a customer order or an employee. To encapsulate the data the BOs are modeled in different layers: Kernel: represents the real data. Integritylayer:representsthebusinesslogicofanobject.Thislayerincludes business rules as well as constraints for values and domains. Interface layer: describes the structure and implementation of the BO. This layer definestheexternalinterfacescalledBusinessApplicationProgramming Interfaces (BAPIs). Access layer: defines the mechanism and technologies to access the object data. ThiscouldbedonebyRemoteFunctionCalls(RFC)orwiththeprogramming language J ava using the SAP J ava Connector. The different layers of a BO are shown in Figure 4. Figure 4: Layers of an SAP Business Obj ect comp. (SAP, 2012) The Interface layer separates the data of a BO from the applications and technologies which accessthedata.ABOjustoffersaninterfacewithclearlydefinedmethods(BAPIs)to access the encapsulated data from outside. An external application can only communicate with a BO through these BAPIs. To access the BO and receive the data, an application just needs the information to call the BAPIs. In this way an application can call the BOs and their BAPIs without knowing specific implementation details of the underlying object. The BAPIs which are provided by a BO represent the behavior of the object. A BAPI can change the internalstructureoftheobjectandthereforethecapsulateddataifitisexecuted.An example of a BAPI for the BO ProductionOrder is the method GetDetail. Inside of a SAP systemallBOtypesandtheirBAPIsaredefinedanddescribedintheBusinessObject Repository (BOR). Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit8 Eachbusinessobjectisreferencedtoaspecificobjectclass.Thisisdependentonthe nature and general characteristics of the object. These object classes are also called object types. Examples are the different production orders PO001 and PO002 which belong to theobjecttypeProductionOrder.Theobjecttypesaredescriptionsortemplatesofthe actual SAP BO. On the other side each single BO is a specific representation or instance of hisobjecttype.InthiscasetheproductionorderwiththeidPO001andthename ProdOrd1 is an instance of the object type ProductionOrder. During the implementation of anapplicationonlytheusedobjecttypesaredefined.Laterduringtheruntimethe application accesses the single instances of this object type. If an instance of a BO is used by an application it can only be accessed through the BAPIs defined by its object type. SAP BO types are defined by the following properties (SAP, 2012): Object type: describes the attributes that all instances of the object type have in common, like the id, the classification or the data model. Inheritanceandpolymorphism:theaimofanobjectorientedtechnologyisthe reusability.Thereusabilitycanbeachievedbyderivationofobjecttypesfrom already existing ones. The BO type ProductionOrder is a sub type of the super type ManufacturingOrder. Key fields: define the structure of a unique identifier. Using this identifier enables an application to access the specific instance of the object type. An example is thekeyfieldProductionOrder.Numberwhichstorestheordernumberofthe object type ProductionOrder. Attributes:containsdataofaBOanddescribes aspecific objectcharacteristic (propertyorattribute).AnexampleistheProductionOrder.ScheduledFinish attribute which holds the scheduled finish date of the order. Methods: a method is an operation which can be executed on the BO to access the underlying object data. Amethod is defined by a name and a sequence of required and optional parameters as well as exceptions. The required parameters have to be filled by the calling application. BAPIs are examples of such methods. AnexampleistheBAPIProductionOrder.GetDetailwhichreturnsdetailorder data. Events: an event indicates that a status change of a BO happens. An example is the ProductionOrder.Released event. 4.1.2.1BAPIs To ease the integration effort BAPIs are developed. BAPIs are methods to execute defined business tasks on SAP BOs. BAPIs can be seen as APIs in object-oriented programming languages. They provide interfaces to access BOs to execute SAP processes, functions or retrieve data. BAPIs can be also enabled to be accessed and executed by external client applications. BAPIsareusuallyaccessedbysynchronouscommunicationandprovidean answer or result set for the calling client application. BAPIs pursue the goal to separate the businesscontentanddata fromthecommunicationmechanism.ConsequentlyBAPIsare independent of the accessing technology and programming language. In general BAPIs do not provide user dialogs to the calling application. Using BAPIs provides the following advantages: Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit9 Standard Interface: BAPIs describe the standard interface of business data stored inanSAPbusinesssystem.Theyenablethetechnicalaswellasbusiness integration of different SAP systems and software components. Stability and downward compatibility: if a BAPI is established and released SAP guarantees to keep the interface definition stable. A change of the underlying SAP systemisthereforeindependentoftheaccess.Subsequentlyalready implemented client applications remain valid. Object orientation Openness Synchronous and asynchronous communication Data base consistency: a BAPI which creates a new BO or changes an existing oneremainsalwaysaconsistentdatabasestate.Alldatabasechangesare entirely executed (as a transaction) or rejected (roll back). Security: without explicit permissions it is not possible to call BAPIs. To call a BAPI the following information are needed: BAPI name: to identify a BAPI it consists of the name of the corresponding BO followed by the BAPI name. Both names are separated by a dot .. Import parameter: data which transfers the calling application to the BAPI Export parameter: data which returns the calling application from the BAPIImport/export (table) parameters: for importing and exporting data ItexistsasaseriesofBAPIswhichareimplementedformostBOtypes.ThoseBAPIs provide basic functions. They implemented certain design rules. They have for example the same name across all BOs. If possible they also have the same sequence of parameters. Examples are: GetList: to retrieve all existing instances of the corresponding BO type. GetDetail: to retrieve detailed information of an instance of a BO type. The BO is referenced by its key field. Create: to create an instance of a BO type. Change: to change an existing BO. Delete: to delete an existing BO. To support a wider range of users and to employ the concept of SOA and web services, the interface of a BAPI can be also modeled as a web service (Enterprise Service). Therefore a wrapperisneededwhichexposestheinterfaceasastandardWSDLfileandcanbe accessed by common web service clients. This is possible through the SOA manager of an SAP system. By using the product SAP NetWeaver Gateway it is also possible to expose BAPIsusingthenewerRESTtechnology.Thedisadvantageofbothpossibilitiesisthe requiredcustomizationoftheSAPsystem.Insteadofusingthealreadyavailableand accessible BAPIs, Web Service or REST wrappers have to be written or at least configured.4.1.3SAP BW / BEx Queries 4.1.3.1Data Warehousing Data warehousing is used by the management for analytics and decision support, so that in Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit10 most cases all data generated in a company is stored in a data warehouse system. The data spansfromcustomer-orientedsupplychaindatauptodataaboutthecompanysown offered products. This data is processed to get information and knowledge about customers, themarketandinternalcompanyprocesses.Theknowledgeisusedtotriggerdedicated actions like the development of new products or services (ITWissen, itwissen.info 2012). TheSAPBusinessInformationWarehouse(BWformerlyBI)istheEnterpriseData WarehousesystemofSAP.Itprovidesdatawarehousingfunctionality,aBusiness Intelligence platformaswellasBusinessIntelligencetools.Italsoallowsintegratingdata warehousingwithotherSAPstandardproducts liketheSAPERPsystem.Theprovided tools allow the integration, transformation and consolidation of business data from productive SAP applications and external data sources in the SAP BW.The following components build SAP BW (SAP, sdn.sap.com 2012): DataWarehousing:classicalfunctionalityofadatawarehousesystem.This includes the integration, transformation, consolidation, data cleaning and storage ofdataforinterpretationandanalytics.TheAdministratorWorkbenchisthe central tool for data warehousing tasks. BIPlatform:technologyplatformoftheSAPBWsystem.Itprovidesthe infrastructure like OLAP processing, metadata repository, planning and simulation possibilities, analytics functionality like data mining and reporting. BI Suite: including Business Explorer. 4.1.3.2Business Explorer The Business Explorer (BEx) is the Business Intelligence Suite of the SAP BW. It is used for analytics to support the strategic management as well as for the operational reporting and decisionsupport.TheBusinessExplorerhastoolstocreatereports,dataqueriesandto analyze the data. It enables analysis of real-time data as well as historical data in different detail levels and perspectives.WiththeBExInformationBroadcastingitispossibletoextracthistoricaldatainformof preprocessed documents out of the SAP BW. That information can be sent via mail or made available for the Enterprise Portal. (SAP, 2012). BEx Query Designer The BEx Query Designer is an application of the Business Explorer to define queries on data stored in the SAP BW. The business data stored in databases is defined as info cubes (also called InfoProviders). With the Business Query Designer it is possible to define queries on those info cubes. By the selection and combination of attributes and key figures, so called info objects, it is possible to view and analyze the information stored in info cubes (SAP, 2012). The process is illustrated in Figure 5. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit11 Figure 5: Analyzing info cubes comp. (SAP, 2012) 4.1.3.3BEx Queri es The BEx Query Designer provides a querying mechanism for data stored in info cubes. By usingBExqueriesthedataofinfocubescanbequicklyanddirectlyanalyzed(SAP, help.sap.com 2012). Queries provide following functionalities: Queriescanbeparameterizedbyusingvariablesforhierarchies,attributes, characteristic values and formulas. Queriescanbefiltered:selectionofcharacteristicvaluesforoneormore characteristics orkeyfiguresissupported.The queried dataofaninfocubeis aggregated to the filter selection. Filter selection is not navigable.Queries can be navigated: selection ofuser defined characteristics and content definition of the rows and columns of queries is supported as well as definition of dataranges ofaninfocubewhichcanbenavigated.Generallyaqueryhasa predefined start view. Using navigation of a query allows the creation of different views on the data stored in info cubes. The queried data from info objects can be limited, filtered and elaborated by definition of: Characteristic values, characteristic intervals, hierarchy nodes Formulas Selections Calculated and limited key figures which can be reused Reusable or local structures Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit12 Exceptions Conditions 4.1.4Web Servi ce According to the W3C Web Services Architecture Working Group, a web service is defined asasoftwaresystemdesignedtosupportinteroperablemachine-to-machineinteraction over a network (Haas & Brown, 2004).Generally, a Web Service provider exposes its capabilities as an interface, abstracting away the implementation details.The interface specifies a set of operations, with input and output parameters.Anoperationinvocationinvolvesanexchangeofmessagesbetweenthe service requester, and service provider. The interface, or contract, is described in anXML-based machine-readable format, called Web ServicesDescriptionLanguage(WSDL).Machinesinteract withthe WebServiceby exchanging SOAP messages, typically using HTTP, in a manner described by the service description.Web Services technology can be used to implement a service-oriented architecture, where SOAP messages are the basic unit of communication. SOAPSOAPisanXML-basedprotocolforexchangingstructured,typedinformationbetween machinesinadistributedenvironment.SOAPwasonceanacronymforSimpleObject AccessProtocol,butthismeaninghasbeendroppedinSOAP1.2.SOAPisakey component in the implementation of Web Services. Raw SOAP is fairly lightweight compared to other distributed computing standards, because it provides only the messaging framework, and relies on other standards to provide other features, suchas registry/discovery, location, transport, security, andguaranteeddelivery. SOAP is based on XML, a familiar and widely-used standard, and retains all the extensibility and machine-readability advantages. It is language and platform independent, and does not define any constraints on the transport protocol to be used, so it is possible to pass through corporate firewalls without the need to open ports. An incomplete summary of the relevant components of the standard is provided in the following paragraphs. The SOAP specification defines a stateless, one-way message transmission between SOAP nodes,butitisexpectedthatapplicationscandefinemorecomplexMessageExchange Patterns (MEPs) by combining one-way exchanges. A message exchange pattern is defined by providing A URI to name the MEP Describe the lifecycle of the exchange with a state machine Describe the temporal/causal relationships between the messages Describe the normal and abnormal termination of the MEP Rules for generating SOAP Faults during MEP operation Thespecificationprovidesaframeworkforconveyingapplicationinformationinan extensiblemanner,butdoesnotconstraintheapplication-specificmessagecontent,or specifyanythingabouttheunderlyingroutingortransportprotocol.ASOAPdocument Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit13 consists of three key elements; the envelope, the header, and the body. Figure 6 shows the structure of a SOAP Message. Figure 6 SOAP Envelope (Mitra & Lafon, 2007)Web Services Description Language (W3C, 2001)TomakeeffectiveuseofWebServices,clientsneedanunambiguous,machine-interpretable description of the interface to the Web Service. The Web Services Description Language(WSDL)specificationfromW3Cwascreatedtoprovideamechanismfor describing the Web Service interface, including: All supported operations Input and output parameters for each operation Types for all parameters, described in XML Schema format Binding address information for each Web Service, including location (URL) and transport protocol AWSDLfileisaformofservicecontract.ThroughitsWSDLfile,theWebServiceis providing an outwardly-descriptive interface, consistent with SOA principles. By locating and parsing a WSDL file, a client has all the syntactic information required to use the operations provided by a Web Service. For more details please refer to Section 9.1.7.4.1.5DPWS Topromoteinteroperabilitybetweenresource-constraineddevices,theDevices Profilefor Web Services (DPWS) defines a minimal set of implementation requirements for dynamic discovery, service description, secure messaging, and events and subscriptions. The goals of the standards are to provide interoperability analogous to Universal Plug and Play (UPnP) fornetworkeddevices,fullyalignedwithWebServicestechnology.Theprofiledefines constraintsonformatsandprotocolssothatWebServicescanbeimplementedon peripheral and consumer electronics-class devices. The general layout of DPWS clients, devices, and services is described in Figure 7. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit14 Figure 7: Arrangement of DPWS Clients, Devices, and Servi ces (Lastra & Delamer, 2006) DPWSdefinesaserviceasasoftwaresystemthatexposesitscapabilitiesbyreceiving and/orsendingmessagesononeofseveralnetworkendpoints.MessagesinDPWSare alwaystransmittedinaSOAPenvelope,generallytransportedviaHTTPandTCP/IP,or SOAP-over-UDP in the case of discovery services. FromaSOAperspective,aDPWS-compliantdeviceisatypeofservicethathostsother services.Thedeviceactsprimarilyasaresourcefordevice-widemetadata,andfor metadata about the services it hosts. A hosted service is outwardly visible, not encapsulated by the hosting service, and is addressed separately from the host.DPWS specifies a set of built-in services that the device must implement: Discovery services, for clients to discover devices, and for devices to announce themselves in a network Services to retrieve device and hosted service metadata Eventing and Subscription Management services, for asynchronous notifications Aclientcandiscoverdevicesinthenetworkthatmatchspecifiedcriteria,retrieveand interpret metadata, invoke operations available in the hosted services, and subscribe to and receive notifications. The web service specifications and transport protocols that are part of the Devices Profile for Web Services are shown in Figure 8. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit15 Figure 8: Network Protocols and Specificati ons included in the Devi ces Profil e for Web Servi ces (Microsoft, 2009) DPWS assembles a set of core web standards, and extends or constrains them to provide a base set of capabilities for resource-constrained devices: Table 1: Speci fi cations in the Devices Profil e for Web Servi ces SPECIFICATIONDESCRIPTION WSDL 1.1The WSDL describes the messages each hosted service is capable of sending and receiving. SOAP 1.2All messages are transported in a SOAP envelope, and additional specs make use of SOAP headers.WS-Addressing (Box D. , 2004)This Specification standardizes endpoint references and message information headers, to convey information typically provided by transport protocols and information systems. A Web Service endpoint is a referenceable entity that can send and receive messages. An endpoint reference can be used to provide information for accessing a Web Service endpoint, or to provide an address for an individual message inside a message information header, along with message characteristics, source and destination addressing, and message identity. DPWS should rely solely on WS-Addressing 1.0, with added restrictions for device identifiers. WS-Transfer (Alexander,Specification that defines a mechanism for acquiring XML-based representations of entities using the Web Services Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit16 SPECIFICATIONDESCRIPTION 2006) infrastructure. It defines two operations for sending and receiving resource representations (Get, Put), and two for creating and deleting (Create, Delete) a resource using a resource factory. DPWS uses the WS-Transfer Get operation as a means for the Client to retrieve resource representation data for a device, which includes relationship metadata for itself and hosted services, and addressing data for the hosted services. WS-MetadataExchange (Daves, 2011)This specification is intended for the retrieval of Web Service Description Information. It defines an encapsulation format for metadata, and treats the metadata about a web service endpoint as a WS-Transfer resource. The specification defines two mechanisms that clients can use to ask a WS-MetadataExchange endpoint for its metadata: GetWSDL/GetWSDLResponse, and GetMetadata/ GetMetadataResponse. DPWS uses the GetMetadata operation to retrieve metadata for a hosted service, which includes the WSDL document. The hosted service can return either the WSDL document, or a reference to the document in a GetResponse envelope.WS-Policy (Vedamuthu, 2007)This specification provides a general framework for specifying a variety of capabilities, requirements, and characteristics of entities in a Web Service-based system. A policy assertion identifies a behavior that is a requirement of a policy subject. A policy alternative is a set of policy assertions. Generally, a policy is used to convey conditions on interaction between two endpoints. A provider exposes a policy to describe the conditions for providing the service. A requester uses policies when deciding whether to use the service. DPWS defines the dpws:Profile policy assertion, indicating that compliance with the profile is required. WS-PolicyAttachment (Baraj, 2006) This specification provides two generalized mechanism for associating policies with the subjects to which they apply. It also specifies how the mechanisms can be used to associate WS-Policy with WSDL and UDDI descriptions. The global attribute wsp:PolicyURIs and child elements wsp:Policy and wsp:PolicyReference are defined, so that resources Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit17 SPECIFICATIONDESCRIPTION can reference applicable policies. DPWS uses this to attach the dpws:Profile policy assertion to a binding in the WSDL file. WS-Discovery (Microsoft, 2009) This specification describes how to announce availability of services, search for services, and locate previously referenced services on a local network using a multicast discovery protocol based on SOAP-over-UDP. Two one-way messages are defined, Hello and Bye, as well as two two-way search messages, Probe and Resolve. Two discovery modes are defined.In ad-hoc mode, clients send probes to a multicast group, and target services matching the search criteria send unicast responses back to the client. The specification also defines multicast hello messages that target services send when they join a network. In managed mode, a discovery proxy receives unicast hello messages from target services, and unicast resolve messages from clients. DPWS specifies that devices must be compliant WS-Discovery target services, but hosted services should not. The profile also specifies additional discovery-related behaviors for devices. WS-Eventing (Box D. , 2006)It is often useful for web services to receive messages when events occur in other services. This specification provides a means to create and delete subscriptions, manage subscription expiry and renewal, and define a preferred delivery mechanism. WS-Eventing provides an extension point called Delivery Modes, and defines a default delivery mode called Push Mode. DPWS requires full support for WS-Eventing, including Push Mode, where the hosted service pushes Notifications to the Event Sink (the client). It also specifies fault behavior, appropriate for distributed, low-resource devices, and support for event subscription filtering by action. DPWS also recommends a security model based on WS-Security, but support is optional, Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit18 and other security models are permitted. DPWS also overrides global constants from other specifications to suit devices, such as packet size limits, timeouts, and delays. 4.1.6MS Excel 4.1.6.1Descripti on MicrosoftExcelis aspreadsheetapplicationincludedintheMicrosoftOfficepackage.An Excel document, called workbook, consists of several sheets. Every sheet contains a grid of cells, in which rows are identified by numbers and columns by letters. This way, a cell can be uniquely identified by a letter and a number. Excel allows to enter numerical values or data into these cells and to use them to perform calculations or to create graphs. Itincludesseveralpredefinedfunctionstocarryoutstatistical,financialandengineering operations. As for graphs, it can display line graphs, histograms, charts, etc. 4.1.6.2Data import and export Microsoft Excel is designed as a stand-alone user application. However, as part of the Office suite, Excel files need to be accessible from outside the application as well. This is possible through two major solutions, Apache POI and OLE Automation, which are described in the followingparagraphs.Athirdalternative,usingcomma-separatedvalues(CSV),isalso wide-spread. Accessing information in that format is done by simply parsing an output file. Since files need to be saved in a format different from the standard format, this approach is not always feasible. Apache POI Apache POI is a J ava library which allows reading and writing Excel files (both XLS and the new XLSX format) among other office applications formats. The API to access to XLS files is called HSSF, while the one related to the XLSX format is called XSSF. Both of them provide: Direct access to low-level structures of those formats. A high level event-based API for efficient read-only access. A full API for creating, reading and modifying files. The following example shows how to iterate over the cells of a workbook: sheet sheet = wb. get sheet at ( 0) ;f or ( i t er at or r i t = sheet . r owi t er at or ( ) ; r i t . hasnext ( ) ; ) { r ow r ow = r i t . next ( ) ;f or ( i t er at or ci t = r ow. cel l i t er at or ( ) ; ci t . hasnext ( ) ; ) { cel l cel l = ci t . next ( ) ;/ / dosomet hi ngher e } } Listing 1 MS Excel Apache POI code example OLE Automation Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit19 OLEAutomationisatechnologyfromMicrosoftthatallowsestablishinganinter-process communicationbyusingCOMobjects.Excel,aswellasallOfficeapplications,provides automation objects to be able to interact with it from other programs. This is an example about how to perform several actions in Excel using Visual Basic Script: Di mexcel AppasObj ectSet excel App= Cr eat eObj ect ( "Excel . Appl i cat i on")excel App. Wor kbooks. Add excel App. Range( "A1: C6") . Sel ectexcel App. Act i veCel l . For mul a= "Hel l oWor l d! " excel App. Vi si bl e= Tr ue Listing 2 MS Excel OLE Automation code example A drawback of OLE Automation is that Microsoft Excel has to be installed in the computer in which its files are going to be read, while Apache POI is a platform-independent standalone solution. 4.1.7MS Project 4.1.7.1Descripti on MSProjectisaprojectmanagementtoolincludedintheMicrosoftOfficepackage.Itis designed to help project managers plan project stages and tasks. Among other features, it allows to: Manage a list of activities in a hierarchical way. Assign resources and costs to the different activities. Track the project status. Analyze workloads. Generate Gantt and network charts. Print reports. The key elements in a project are: Tasks: A project is broken down into several tasks, which are the steps needed to complete it. They can be parallel or sequential. Besides, a task can be repetitive if itarisesataregularintervalduringtheproject.Ataskiscomposedofan identifier, a name, duration and a date. Milestones:Milestonesrepresentintermediategoals,eventsorconditionsthat affecttoagroupoftasks.Incontrasttotasks,milestonesdonothavean associated duration or effort. Resources: They include the people, materials and equipment necessary to carry outtheprojecttasks.Resourcesaredefinedinaresourcesheetandtheyare assigned to tasks. It is also possible to share them between several projects. 4.1.7.2Data import and export MicrosoftProjectisnotprimarilydesignedwiththegoalofdataexchangebetween applications.TherearepossibilitiestoaccesstheinformationinsideaMSProjectfile, however. These possibilities are based on the MPXJlibrary and OLE Automation, which are described in the following paragraphs. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit20 MPXJ library MPXJis a J ava library which allows to access project information from several file formats: MicrosoftProjectExchange(MPX),MicrosoftProject(MPP,MPT),MicrosoftProjectData Interchange(MSPDIXML),MicrosoftProjectDatabase(MPD),Planner(XML)and Primavera (XER and database). The native MS Project file format (MPP) can only be read; it does not support writing. The same API can be used to access to all the supported formats. In order to allow this, MPXJ definesasetofclassesthatencapsulatethekeyentitiesthatmakeupaproject: Project, Resource, Task, Resource Assignment and Calendar. The following example shows how to iterate over the resources defined in a MS Project file: Pr oj ect Reader r eader = new MPPReader ( ) ;Pr oj ect Fi l epr oj ect = r eader . r ead( "exampl e. mpp") ;f or ( Resour cer esour ce: pr oj ect . get Al l Resour ces( ) ) { Syst em. out . pr i nt l n( "Resour ce: "+ r esour ce. get Name( ) + "( Uni queI D="+r esour ce. get Uni queI D( ) + ") ") ;} Listing 3 MS Proj ect MPXJ library resource i teration example This example demonstrates how to read the task hierarchy: publ i cvoi dl i st Hi er ar chy( Pr oj ect Fi l ef i l e) { f or ( Taskt ask: f i l e. get Chi l dTasks( ) ) { Syst em. out . pr i nt l n( "Task: "+ t ask. get Name( ) ) ;l i st Hi er ar chy( t ask, "") ;} Syst em. out . pr i nt l n( ) ;} pr i vat evoi dl i st Hi er ar chy( Taskt ask, St r i ngi ndent ) { f or ( Taskchi l d: t ask. get Chi l dTasks( ) ) { Syst em. out . pr i nt l n( i ndent + "Task: "+ chi l d. get Name( ) ) ;l i st Hi er ar chy( chi l d, i ndent + "") ;} } Listing 4 MS Proj ect MPXJ library task reading example The following example enumerates the resources assigned to the project tasks: f or ( Taskt ask: f i l e. get Al l Tasks( ) ) { Syst em. out . pr i nt l n( "Assi gnment sf or t ask"+ t ask. get Name( ) + ": ") ; f or ( Resour ceAssi gnment assi gnment : t ask. get Resour ceAssi gnment s( ) ) { Resour cer esour ce= assi gnment . get Resour ce( ) ;St r i ngr esour ceName; i f ( r esour ce== nul l )r esour ceName= "( nul l r esour ce) ";el se Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit21 r esour ceName= r esour ce. get Name( ) ; Syst em. out . pr i nt l n( ""+ r esour ceName) ;} } Listing 5 MS Proj ect MPXJ library resource enumerati on example OLE Automation As Microsoft Project is a member of the Office package, it can also be controlled with OLE Automation by using COM objects. This is an example about how to add a new task to a project and save it to a file using Visual Basic Script: Di mpj AppAsObj ectSet pj App= Cr eat eObj ect ( "MSPr oj ect . Appl i cat i on")pj App. Vi si bl e= Tr ue pj App. Fi l eNewpj App. Act i vePr oj ect . Tasks. Add"New t ask" pj App. Fi l eSaveAs"Pr oj ect Fi l e. mpp" pj App. Fi l eCl ose pj App. Qui tListing 6 MS Project OLE Automation code example 4.1.8OPC Unified Architecture OPCUAisarelativelynewspecificationfromtheOPCFoundationfordataexchange betweensystemsinindustrialapplications,basedonweb-serviceconcepts.OPCUAis designedforaccessinglargeamountsofreal-timedevicedatausingstandardnetwork infrastructure,whilemaintainingsufficientlyhighperformance.OPCUAspecifies aclient-servermodelforinformationexchange,whereaclientcanaccess,read,andmodifythe addressspaceofaserver.Thespecificationdefinesanobjectmodelforinformation representationonaserver,andapre-definedsetofservicesforbrowsing,querying, creating, and manipulating objects in the address space. Information is communicated using OPC UA- and vendor-defined data types, encodings, and transport mappings OPC UA evolved from classic OPC, which was a data access for Windows-based systems, using Microsofts OLE, COM, and DCOM technologies. OPC was formerly an acronym for ObjectLinkingandEmbedding(OLE)forProcessControl,butthisacronymhasbeen dropped.ThestandardwasdevelopedtobridgeWindowssystemsandprocesscontrol devices, and defines standard objects, methods, and interfaces for retrieving field data from devices on the factory floor. A vendor would implement an OPC server for their hardware, which would provide a method for any OPC client to access device data for use in any MES, ERP, HMI/SCADA, or other system. The OPC UA specification eliminates the reliance on COM/DCOM, and specifies a platform-independent, service-based communication model, and a richer, integrated address space model. In the interest of security and performance, OPC UA defines two data encodings: UABinary:Thespecificationdefinesanon-portablebinarymessageencoding, optimized for message size, and fast encoding and decoding. The specification relies on a set of primitive data types, for which binary encodings are defined. The encodingexcludestypeandfieldnameinformation,becauseapplicationsare expected to have advance knowledge of the services and data structures being Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit22 transmitted. UAXML:ThespecificationalsodefinesaplaintextXMLrepresentationof elementsintheobjectmodelforSOAP/HTTPwebservices.TheUAXML encoding uses the formats defined in the W3C XML Schema specification. Furthermore, two transport mappings are defined: UA TCP (UA Native): A TCP-based OPC UA-specific protocol for establishing a full-duplexchannel fortransmittingbinarydatabetweenanOPCUAclientand server.UnlikeHTTP,responsescanbereturnedinanyorder,andallows responses to be returned on a different socket, if communication failure causes an interruption. OPC TCP is designed to work secure SecureChannel, implemented at a higher layer. SOAP/HTTP (Web Service): OPC UA messages are serialized to XML, wrapped in a SOAP envelope, and exchanged using the request-response model defined intheSOAPspecification.HTTPorHTTPStransportbindingsareused.A message is sent in the body of a POST request, and the response comes in the HTTP response. Theclient-servercommunicationparadigmofOPCUAlendsitselfwelltohierarchical application architectures. A higher level client application retrieves data and writes values to a lower-level server. Application layers can be stacked by having an OPC UA server and client running on the same component, as shown in Figure 9. Each component running an OPC UA Server manages its own address space. The server can map nodes in the address space to IOs on devices in a connected fieldbus network or PLCmemory, or exposedatafrom adatabase.Asingle OPC UA serverintegratesdata, type definitions, alarms and events, and historical data into its address space. The server supports a set of web services, which a client can use to establish a session, browse and query the address space, subscribe to notifications, and invoke object methods. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit23 Figure 9: OPC UA Stacked Architecture OPCUnifiedArchitectureis fundamentallyaboutdatamodellingandtransport.Inclassic OPC, only pure data was provided, such as raw sensor values, with only limited semantic information, such as the tag name and the engineering unit. OPC UA offers more powerful capability for semantic modelling of data. OPCUAusesobject-orientedtechniques,includingtypehierarchiesandinheritance,to model information. Type information is stored on servers and accessed in the same way as instances,similartorelationaldatabasesystems.TheOPCUAnodemodelallowsfor informationtobeconnectedinvariousways,byallowingforhierarchicalandnon-hierarchical reference types. This facilitates exposing the same information in many ways, dependingontheusecase.Boththetypehierarchiesandreferencestypescanbe extended, allowing information models of existing systems to be exposed natively, without the need for mapping between models. Information models are always contained in an OPC server, so an OPC client is not required to have an integrated OPC UA information model. The base OPC UA specifications provide only the infrastructure to model information, and encourageadditional,industryspecificinformationmodelspecificationstobedefinedby vendorsandstandardsorganizations.Developmenthasbegunonabasemodelfor exposingdeviceinformationanddevicetypesinOPCUA(UADevices),whichcanbe extended with vendor-specific information. Also, efforts are underway to expose the ISA 95 (also known as IEC 62264 (International Electrotechnical Commission, 2003)) model in OPC UA to provide information to MES and ERP systems. 4.1.9SQL TheSQL(StructuredQueryLanguage)(ISO/IEC9075:1992,1992)isaprogramming languagedesignedespeciallyforaccesstorelationaldatabasemanagementsystems (RDBMS). SQL belongs to the family of data manipulation languages (DML). It is used to retrieveandmanipulatedatainRDBMS-inserting,deletingandupdatingdataina database. There are several approaches to get or manipulate data in database, as described Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit24 in the following sections. 4.1.9.1SQL Statements SQL is the most widely used database language and offers the following base queries and statements for data retrieval and data manipulation: SELECT ... FROM ... WHERE ...: this query statement retrieves data from one or moredatabasetables,orexpressions.Thereturneddataarearesultsetof records.ItisthemostcomplexSQLstatementandprovidesalotofoptional keywords and clauses that make possible the more granular data retrieval. The standardSELECTstatementdoesnotchangethedatainthedatabaseandis purely read-only query. INSERT INTO ... VALUES ...: this statement adds rows to an existing database table. UPDATE ... SET ... WHERE ...: this statement modifies a set of existing rows in the database table. DELETEFROM...WHERE...:thisstatementremovesexistingrowsfroma database table. 4.1.9.2Stored procedures InsteadofusingtheSQLstatementsdirectly,theRDBMSusuallyofferthestored procedures or functions that wrap them. This means that for a SQL statement that is often used, a stored procedure can be created and stored in the database and such a procedure can be executed in the SQL database to manipulate the data or to retrieve some data from thedatabase.ThestoredprocedurecancontainseveralSQLstatementsanditsbig advantageisthatalltheSQLstatementsinthestoredprocedurearedoneinasingle transaction, so in case of any error all the changes in the database can be reverted. 4.1.9.3Procedural languages support TheRDBMSalsoofferstoexecutethecodewritteninprocedurallanguages.Examples couldbePL/SQLandJ avausedinOracledatabaseserver(Oracle,2005)orCLR.NET Framework procedures used in Microsoft SQL Server (Microsoft, 2011). 4.1.9.4PL/SQL PL/SQL (Oracle, 2012) is a procedural language extension to SQL provided by Oracle. It provides a server-side, stored procedural language that is easy-to-use, seamless with SQL, robust,portable,andsecure.PL/SQLenables mixingofSQLstatementswithprocedural constructs. With PL/SQL, a PL/SQL program can define and run units such as procedures, functions, and packages. PL/SQL program units generallyarecategorized as anonymous blocks and stored procedures. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit25 Figure 10: The PL/SQL Engine and the Oracle Database Server (Oracle, 2005) 4.1.9.5Java A J ava stored procedure (Oracle, 2012) is a program written in J ava to run in the Oracle server,exactlyasaPL/SQLstoredprocedure.Itisinvokeddirectlywithproductslike SQL*Plus, or indirectly with a trigger. It can be accessed from any Oracle Net client OCI, pre-compiler, or J DBC. Inaddition,J avacanbeusedtodeveloppowerfulprogramsindependentlyofPL/SQL. Oracleprovidesafully-compliantimplementationoftheJ avaprogramminglanguageand J VM. 4.1.9.6SQL CLR The common language runtime (CLR) (Microsoft, 2011) is the heart of the Microsoft .NET Framework and provides the execution environment for all .NET Framework code. Microsoft SQL Server integrates the CLR component of the .NET Framework for Microsoft Windows. ThismeansthatSQLServerusersandapplicationdeveloperscanwritethestored procedure, triggers, user-defined types, user-defined functions, and user-defined aggregates inmanagedcodeusingany.NETFrameworklanguage,includingMicrosoftVisualBasic .NET and Microsoft Visual C#. The major benefits of the CLR integration are: Better programming model Improved safety and security Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit26 Ability to define data types and aggregate functions Streamlined development through a standardized environment Potential for improved performance and scalability. 4.1.9.7Transacti ons TransactionisalogicalunitofworkthatcontainsoneormoreSQLstatements(Oracle, 2005). It is an atomic unit and the effects of all the SQL statements in a transaction can be either committed (applied to the database) or rolled back (undone from the database). Thetransactionsareveryimportanttoensuretheintegrityofthedata.Itmeansthat transactions help to keep all the data in the RDBMS in a valid, consistent, complete form. 4.2Adapter roles The adapter roles that have been defined in the beginning of section 4 need to be defined in more depth in order to make them usable for the PLANTCockpit project. The use cases of PLANTCockpit offer a typical set of example adapter roles that warrant a closer inspection. The role of an adapter needs to be identified, though. In order to prepare a model of adapter roles that can be applied to the external systems of the PLANTCockpit use cases, the roles need to be structured and described according to their semantics. Since the exact semantics of data are not yet fully defined, this document will only offer a grid of subdivisions of the general role of an external system. The work on the Mapping and Transformation Layer will detail the concrete roles that are used in a PLANTCockpit system. The list of roles that the usecasesystemsidentifiedasrelevanttoPLANTCockpitcanbedividedintofourmain areas of interest. These four areas are production planning, resource planning, logistics and energymanagement.Naturally,dependingonthepartnersusecase,thefocusedarea differs. 4.3Non-functional properties of adapters Apart fromtheobvioustaskofacquiring datafromexternalsystems,thereareadditional properties of the PLANTCockpit adapters to be considered. These non-functional properties are discussed in this section. The first issue to be addressed is the fact that in addition to adapter types and adapter roles, there is the adapter instance. The instance is a separate program entity that is the intersection point between adapter type and adapter role. Each instance of the PLANTCockpit adapter has a specific configuration that adds to the role and type of the instance. This configuration information has to provide data on crucial operations of the adapter. First of all, the adapter needs to be properly identifiable through its configuration information. This is in addition to the functional necessities imposed on the configuration information, which encompasses the information needed to retrieve the data the adapter is meant to acquire. An important design decision for the PLANTCockpit adapters was the separation of systems for security purposes. Granting only limited access to a system can help prevent exploitation of information and other attacks. The security issues regarding adapters are named in D3.2. Anotherimportantpropertyisthecomputingperformanceofadapters.Dependingonthe connectedexternalsystem,thefrequencyofdataacquisitioncanvarywidely.Data throughput,also,hasavaryingdimensiondependingontheadapterinstance.Itisnot Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit27 possibletoformulategeneralguidelinesforcomputingperformanceofadaptersperse, exceptthateachadapterhastomakesurethatitscomputingpowerconsumptionis optimised. For implementing the adapters, different philosophies can be applied. One possibility is to make an adapter type as flexible as feasible. Then one adapter type covers a wide range of applicationsthatarerelatedonanaccess-technicallevel.Thisreducesthenumberof adapter types that have to be implemented. It does, however, make each adapter instance heavy-weight,withalotofconfigurationtobeheldjusttodifferentiatebetweendifferent possible applications. In the opposite case, a highly specialised adapter type can be tailored towards accessing a well-defined piece of data in an external system. This can reduce the amount of configuration to be maintained to zero. The effort for implementing a lot of new specialised adapter types whenever a change in the data focus occurs makes this approach unfeasible,though.Hence, abalancebetweenthetwoextremesshouldbesoughtwhen implementing adapter types. The importance of configuration information for the adapter instances makes it necessary to differentiatetheexternalinterfacesofanadapter.Forone,thereneedstobearuntime interface,whereotherfunctionblockscanrequestdatafromexternalsystemsfromthe adapter. In addition, there needs to be a configuration interface. This interface should allow access to an adapters configuration information. When setting up a function block network inPLANTCockpit,theuserwillneedaccess totheconfigurationinformationandalsowill need to manipulate it. PLANTCockpitshouldbeasflexibleaspossibleregardingitsdataacquisition.Itis impossible to prepare the framework for every possible data source in advance. New data sourcesmustbefilledwithmeaningduringtheruntimeofPLANTCockpit,ifneedbe. Therefore,adaptersneedtoreceivetheirconfigurationinformationfromflexibledata structures.Thesedatastructuresshouldbeabletocarrythesemanticsofdatasources. That way, when a new system is connected to PLANTCockpit, it can be mapped onto the semantics easily and from there the mapping on the PLANTCockpit-internal formats can be done automatically. Alltheseconsiderationshavebeenafactorindecidingthedraftfortheinterface specificationofthePLANTCockpitadapters.Thefollowingsectiondescribesthese interfaces. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit28 5Abstract interface speci ficati on of the PLANTCockpi t Adapters As has been established in D3.1, the data processing logic of PLANTCockpit is structured on function blocks. While theFunction block engine is not in thescope ofthis deliverable, a conceptforcombiningadaptersandfunctionblockshasbeendevelopedthatwillbe introducedhenceforth.FromtheviewoftheFunctionEngine,anadapterisjustlikeany other function block. The adapter passes on data just like any other function block would. Whatmakestheadapterdifferent,however,isitshybridnature.Whileoneendofthe adapterislinkedintotheFunctionEngine,theotherendisspecifictotheaddressed technology and directly accesses the corresponding external system. The concept of adapters as function blocks can be seen in Figure 11. Note that a colour-codinghasbeenappliedthatmatchestheonefoundinD3.1,whereelementsofthe Function Engine are blue, elements of the External System Connector Layer are green and elementsthatdonot belongtoPLANTCockpit arewhite.Theillustrationofthedataflow given in the figure matches typical data flow illustrations found in function block concepts fromthemanufacturingdomain,suchastheonegiveninIEC61499(International Electrotechnical Commission, 2005), e.g. Figure 11 PLANTCockpit adapters as function blocks Notethattheadaptershavetwocharacteristics,asdescribedinsection4.Theupper labelling identifies the adapter role, as exposed to PLANTCockpit. The lower one identifies theadaptertype,whichisthecriticalpropertyforaccesstothecorrespondingexternal system. In the example shown, both the Database and the Excel file contain a production order.Therefore,twoadaptersexposethesameroletowardsPLANTCockpit.Forthe function blocks interacting with both adapters, there is no technical difference between them. The heterogeneity of the data source is masked by the adapters. In addition to this definition of adapters as function blocks, more details need to be specified Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit29 in order to allow interface implementation for the adapters. While a first draft is given here, a moredetailedspecificationforusebyprogrammersingeneralwillbegiveninD4.3. Adapters in general need to expose three interfaces that allow querying and manipulation. The first interface to be exposed is an interface used for querying identification information from the adapter. The second interface is used for configuration of the adapter. The third interfaceisaruntimeinterfacefortriggeringtheperformanceoftheadaptersdata acquisitionroutine.Figure12showsthethreeinterfacesofthePLANTCockpitadapter, which will be described in more detail hereafter. Figure 12 The interfaces of the PLANTCockpit adapter TheIdentificationinterfaceoftheadapterallowsacquiringinformationabouttheadapter type, the adapter role and the adapter instance. An identification constant can be used to unambiguously identify the adapter type. This is meant to help the configurator in making sure that a fitting adapter is used for a specific data source. The same method used for the adapter role allows verifying that a specific adapter is used correctly in PLANTCockpit. The identificationoftheadapterinstancecanbe usedinthemessagebrokerasdescribedin D7.1. The operations exposed by the IIdentification interface are listed here: Table 2 IIdentification interface descriptions IIdentification interfaceDescription getAdapterTypeID()Returns an ID tag specific for the adapter type that is implemented by this adapter instance getAdapterTypeName()Returns a name tag specific for the adapter type that is implemented by this adapter instance getAdapterTypeVersion()Returns a version number identifying the version of the adapter type definition implemented by this adapter instance Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit30 getAdapterRoleID()Returns an ID tag specific for the adapter role that is assigned to this adapter instance getAdapterRoleName()Returns a name tag specific for the adapter role that is assigned to this adapter instance getAdapterInstanceID()Returns an ID tag specific for the adapter instance getAdapterInstanceName()Returns a name tag specific for the adapter instance Theconfigurationinterfaceoftheadapterallowsaccesstotheconfigurationinformation stored for each adapter. This covers acquisition and writing of the data access specifics for theexternalsystemaswellasPLANTCockpit-specificaddressingandsophisticated information about the semantics of the adapter. The message IDs accessible here can be usedinthemessagebrokerasdescribedinD7.1.Theoperationsexposedbythe IConfiguration interface are listed here: Table 3 IConfiguration interface descriptions IConfiguration interfaceDescription getInstanceConfiguration()Returns an XML construct that contains the configuration information of this adapter. Specifically, information about how to access the external data source and what data is focused there is contained setInstanceConfiguration()Passes an XML construct that contains the configuration information for this adapter. Specifically, information about how to access the external data source and what data to select from it is contained getMessageIDList()Returns a list of message IDs corresponding to the messages that are generated whenever the execute operation (see below) is successfully run setMessageIDList()Passes a list of message IDs corresponding to the messages that have to be generated whenever the execute operation (see below) is successfully run getAdapterSemantics()Returns a data struct that contains semantic information about the adapter, e.g. the role of the source system and the corresponding meaning of the data that is acquired through Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit31 the adapter setAdapterSemantics()Passes a data struct that contains semantic information about the adapter, e.g. the role of the source system and the corresponding meaning of the data that is acquired through the adapter The runtime data interface allows the execution of the data acquisition routine defined in the adapter. This interface can be triggered in three ways. First, a function block can trigger the interface from the PLANTCockpit side of the adapter, generating a response message on demand.Second,aninternaltimerintheadaptercantriggertheinterface,generatinga message in a set time interval, ready for all subscribers to the outgoing message queue to consume.Third,anexternalsystem,towhichtheadaptersubscribed,cantriggerthe interface by sending an event or alarm. Then a message is generated and passed into the PLANTCockpit message queues, where all subscribers to the adapter receive it by means of the PLANTCockpit message queue. (See D7.1 for more details on message queues.) Table 4 IRuntimeData interface description IRuntimeData interfaceDescription execute()This operation is the central data acquisition activity that can be triggered in different ways and ends up generating an outgoing message with the specified data wrapped in a PLANTCockpit-compatible way The interfaces described in this section will become part of a reference implementation of adapters for PLANTCockpit. The reference implementation and an update on the interfaces will be given in D4.3. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit32 6Abbreviati ons The following table lists the abbreviations used throughout the document. Table 5 Abbreviations AbbreviationLong Version B2MMLBusiness to Manufacturing Modelling Language BAPIBusiness Application Programming Interface BExBusiness Explorer BOBusiness Object BWBusiness Information Warehouse COMComponent Object Model DCOMDistributed Component Object Model DPWSDevices Profile for Web Services ERPEnterprise Resource Planning GUIGraphical User Interface HTTPHypertext Transfer Protocol IDIdentifier IDLInterface Definition Language IECInternational Electrotechnical Commission IOInput/Output IPInternet Protocol ISOInternational Organization for Standardization KPIKey Performance Indicator MESManufacturing Execution System MSMicrosoft OPCOpenness, Productivity, Collaboration (formerly Object Linking and Embedding Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit33 (OLE) for Process Control) OPC UAOPC Unified Architecture PLCProgrammable Logic Controller RPCRemote Procedure Call SOAService-Oriented Architecture SOAPSimple Object Access Protocol SQLStructured Query Language TCPTransmission Control Protocol UDPUser Datagram Protocol W3CWorld Wide Web Consortium WPWork Package WSWeb Service WSDLWeb Services Description Language XMLExtensible Markup Language Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit34 7Conclusion ThisdocumentdescribestheadaptersofPLANTCockpit,whichserveasconnectorsto external systems. It offers a first draft of the specification of external interfaces, which will receive mapping and transformation support in D4.2 and will be specified more concretely after the initial implementation experience has been gathered in D4.3. The main achievements of this document are the identification of adapters as function blocks withadditionalcapabilities,aswellasthedifferentiationbetweenadaptertypesonthe technical and adapter roles on the semantic level. While the defined interfaces offer a basis fortheimplementationofreferenceadaptersaswellasusecasespecificadapters,the considerationsregardingsemanticsarethebasisforthedesignofthemappingand transformation framework in the upcoming period of the project. Thesectiononadaptertypesprovidesanoverviewofthetechnologiesthathavetobe addressedwithPLANTCockpitsexternalinterfaces.Extensivediscussionsandexamples provide a guideline for programmers who want to implement adapters. The identification of requirements for adapters is taken to the non-functional level as well. This is expanded by the Annex, where an example for mapping of data is given. Tying the adapters seamlessly into PLANTCockpit is a critical step towards a success of the overall project. Externaldatais thefoundationofeverythingelsePLANTCockpitwants to achieve. Making the connection as easy for the users as possible is a goal that will have to be kept in mind during the future work in the project. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit35 8References Alexander, J . (September 2006). Web Services Transfer (WS-Transfer). Von World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/WS-Transfer/ abgerufen Baraj, S. (April 2006). Web Services Policy 1.2 - Attachment (WS-PolicyAttachment). Von World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/WS-PolicyAttachment/ abgerufen Box, D. (2004). Web Services Addressing. Von World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/ws-addressing/ abgerufen Box, D. (March 2006). Web Services Eventing (WS-Eventing). Von World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/WS-Eventing/ abgerufen Cristcost. (December 2007). Wikimedia Commons Image. Abgerufen am 31. 1 2012 von http://en.wikipedia.org/wiki/File:WSDL_11vs20.png Daves, D. (September 2011). Web Services Metadata Exchange (WS-MetadataExchange). Von World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/WS-Transfer/ abgerufen Haas, H., & Brown, A. (February 2004). Web Services Glossary, World Wide Web Consortium (W3C) Working Group Note. Abgerufen am 31. J anuary 2012 von http://www.w3.org/TR/ws-gloss/ International Electrotechnical Commission. (2003). IEC 62264 - enterprise - control system integration. International Electrotechnical Commission. (2005). IEC 61499 - Function blocks. ISO/IEC 9075:1992. (30. J uly 1992). Database Language SQL. Von http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt abgerufen Lastra, J ., & Delamer, M. (2006). Semantic web services in factory automation: fundamental insights and research roadmap. Industrial Informatics, IEEE Transactions on, vol.2, no.1, 1-11. Microsoft. (J uly 2009). Additional WS-Discovery Functionality. Von MSDN Library: http://msdn.microsoft.com/en-us/library/bb736556(v=VS.85).aspx abgerufen Microsoft. (2011). Overview of CLR Integration. Abgerufen am 29. 02 2012 von Microsoft Technet: http://technet.microsoft.com/en-us/library/ms131045.aspx Mitra, N., & Lafon, Y. (April 2007). SOAP Version 1.2 Part 0: Primer (Second Edition), World Wide Web Consortium (W3C) Recommendation. Abgerufen am 31. 1 2012 von http://www.w3.org/TR/soap12-part0/ Oracle. (2005). SQL, PL/SQL, and Java. Abgerufen am 29. 02 2012 von Oracle Database Documentation Library: http://docs.oracle.com/cd/B19306_01/server.102/b14220/sqlplsql.htm Oracle. (2005). Transaction Management. Abgerufen am 29. 02 2012 von Oracle Database Documentation Library: http://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm Oracle. (2012). Oracle Database Java Developer's Guide. Abgerufen am 29. 02 2012 von Oracle Database Documentation Library: http://docs.oracle.com/cd/B19306_01/java.102/b14187/toc.htm Oracle. (2012). Oracle Database PL/SQL User's Guide and Reference. Abgerufen am 29. 02 2012 von Oracle Database Documentation Library: http://docs.oracle.com/cd/B19306_01/appdev.102/b14261/toc.htm SAP. (2012). help.sap.com. Von http://help.sap.com abgerufen Vedamuthu, A. (September 2007). Web Services Policy 1.5 Framework. Von World Wide Web Consortium (W3C) Recommendation: http://www.w3.org/TR/ws-policy/ abgerufen W3C. (March 2001). Web Services Description Language (WSDL) 1.1. Von W3C: http://www.w3.org/TR/wsdl abgerufen World Batch Forum. (October 2008). Business to Manufacturing Markup Language. Abgerufen am 31. J anuary 2012 von http://www.wbforg.affiniscape.com/associations/12553/files/B2MML-V0400.zip Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit36 9Annex InordertospecifytheinterfacesofthePLANTCockpitadapters,ananalysisofinterface definition languages has been performed. The results of this analysis have been deemed useful for the project, and therefore are given in this Annex. An IDL is a programming language independent notation to describe the services offered by asoftwarecomponent.TheyarecommonlyusedinRPC(RemoteProcedureCall),Web ServicesandComponentSoftwaretechnologies,likeMicrosoftsCOM/DCOM,Mozillas XPCOM, etc. 9.1Interface definition languages 9.1.1OMG IDL OMG IDL is a well-known interface definition language created for the Component Object Request Broker Architecture (CORBA) standard. It has a simple and easy to learn syntax, very close to C++or J ava. This is an example of how an OMG IDL interface looks like: modul eSer ver s{ i nt er f aceTCPSer ver { / / At t r i but es at t r i but el ongpor t ;r eadonl yat t r i but est r i nghost name; / / Oper at i ons voi dl i st en( i nl ongpor t , out bool eansuccess) ;}; i nt er f aceHTTPSer ver : TCPSer ver { voi dhandl eGet ( ) ;voi dhandl ePost ( ) ;};};Listing 7 OMG IDL interface example code Apart from operations and attributes, OMG IDL supports the following primitives: Modules:Interfacescanbegroupedinmodules.Thisisusefultoavoidname clashes. Oneway operations: These are special non-blocking operations. Exceptions: Operations can raise exceptions to indicate error situations. Inheritance: An interface can inherit from others, in a similar way as inheritance works in object-oriented programming languages. Types: oBasic types: It supports the most common basic types, like float, double, long, char oConstructed types: It provides three mechanisms to create new types from others, similar to the ones provided by the programming languages: Structs: They allow to group together several related items. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit37 Unions:They areutilizedtogroupseveralitems,but only oneof them can be used. Enumerated types: They allow to group a set of related constants. oArrays. oTemplate Types: Sequences: They are used to represent lists of objects. Strings: A string is a sequence of characters. Constants. Type declaration. Forward declaration. Scoped names. 9.1.2Mi crosoft Interface Definition Language (MIDL) MIDL is an interface definition language developed by Microsoft, though is basically based on OMG IDL. It only adds some small features to support COM/DCOM interfaces. It was mainly created to support RPC and COM/DCOM interfaces, though it also generates type libraries for OLE automation. Therefore, the provided tools are oriented towork with those technologies. 9.1.3XPIDL XPIDL (Cross Platform Interface Description Language) is an interface definition language developed by Mozilla. Its main purpose is to specify XPCOM interfaces. AsMIDL,itisbasedonOMGIDL.ItisextendedwithsyntaxtohandleIIDsandsome additional types. 9.1.4Apache Thrift Thrift is not only aninterface definitionlanguage, but also a completesoftware stack that includes a code generation tool to develop RPC services. Thrift uses C-style syntax to define the interfaces. A Thrift interface looks like this: st r uct Temper at ur eSensor { 1: i 32busAddr ess,2: st r i ngname,3: bool enabl ed } ser vi ceSensor Ser vi ce{ voi daddSensor ( 1: Temper at ur eSensor sensor ) ,Temper at ur eSensor get Sensor ( 1: i 32busAddr ess)} Listing 8 Thrift interface code example The language provides the following items: Basic types: bool, byte, i16, i32, i64, double, string and binary. Structs. Containers: ordered lists, unordered sets and maps. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit38 Exceptions. Services: They are equivalent to interfaces in object oriented programming. 9.1.5Apache Etch Etch,asThrift,isacross-platformRPCframeworkdevelopedbyCiscoSystems.To describe those services, it includes an interface definition language called Etch IDL. Etch IDL uses J ava-style syntax and looks like this: modul et est @Di r ect i on( Bot h)ser vi ceTemper at ur eSer vi ce { @Aut hor i ze( i sLoggedI n)i nt get Temper at ur e( ) @Aut hor i ze( i sLoggedI n)i nt get Uni t s( ) voi dcheckSt at us( ) t hr owsBadSensor Except i on } Listing 9 Etch IDL interface code example The language provides the following elements: Basic types: Boolean, byte, short, int, double, string Extended types: Datetime, List, Set and Map. Object data type. Constants. Enumerations. Arrays. Exceptions. Messages: They are equivalent to functions in programming languages. Includes. Services: They are used to group messages. Annotations: They areusedto alter the behavior ofthe followingstatement, for example,toimplementauthorization,toexpressmessagedirection,toindicate timeouts Modules: They work in a similar way as J ava packages. 9.1.6Apache Avro Apache Avro is a data serialization system that also provides RPC mechanisms. It includes an interface definition language called Avro IDL. An Avro IDL document consists of one protocol definition, which may include definitions of messages, data types or imports of external protocols. It uses J ava-C++style notation. This is how an Avro IDL document looks like: @namespace( "or g. pl ant cockpi t . t est ") Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit39 pr ot ocol Sensor { enumKi nd{TEMPERATURE, HUMI DI TY} r ecor dSensor { st r i ngname;Ki ndki nd;I nt busAddr ess;ar r ay l ast Val ues;} er r or Sensor Er r or { st r i ngmessage;} st r i ngget Sensor Devi ceType( ) ;i nt get Temper at ur e( i nt uni t s) ;voi d`er r or `( ) t hr owsSensor Er r or ;voi dpi ng( ) oneway;} Listing 10 Avro IDL interface code example The language provides the following items: Protocols: A protocol is used to group messages and type definitions. Imports: An Avro IDL document can import protocols defined in other files. Enumerations. Records: They are similar to C structs. Primitive types: It includes support for int, long, string, Boolean, float Messages: They are equivalent to functions in programming languages. Annotations: Annotations are used to add additional properties to types and fields. 9.1.7WSDL The current W3C recommendation is WSDL 2.0, but WSDL 1.1 is still relatively widely used.The structure of the documents is quite similar for both versions, as illustrated in Figure 13. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftClassificationPU PLANTCockpit40 Figure 13: WSDL 1.1 and 2.0 Document Structure(Cristcost, 2007) Table 6: Structure of WSDL 1.1 and WSDL 2.0 files WSDL 1.0 (WSDL 2.0) Descripti on definition(description) The root element of the WSDL document. It defines the service name, and the namespaces used in the document. types (types) The types section describes the input and output parameters of operations in XML Schema format. This is all the type information needed for the information exchange between the service consumer and provider. External XML Schemas (.xsd files) can also be imported. message (N/A) Messages contain the information required to complete the operation, and contain zero or more message parts, representing parameters.The parts have name attributes, unique within the message, and reference elements in the types section. Messages do not specify direction. In WSDL 2.0, messages are eliminated, and the input and output parameters of the operations simply reference the types directly. portType(interface) This defines the Web Service and each operation that the port exposes. Project - No260018 Date13/04/2012 Technical Report - External interface specification, first draftCla