Machine to machine architecture
11012515 · 2021-05-18
Assignee
Inventors
Cpc classification
H04L41/0266
ELECTRICITY
H04L67/025
ELECTRICITY
H04L67/34
ELECTRICITY
H04L67/125
ELECTRICITY
H04L41/028
ELECTRICITY
H04L41/0273
ELECTRICITY
International classification
Abstract
A machine-to-machine communication platform provides a flexible system for device control and solution hosting. In particular, the communication platform hosts and manages third party vertical solutions that interact with external devices. A third party gateway provides the third parties with access to the communication platform so that the third parties may define, configure, and monitor custom vertical solutions that are locally hosted in the communication platform. The communication platform provides a communication manager that implements a device independent communication facility for communicating with the external devices. As a result, the communication platform connects to, communicates with, and controls virtually any external device.
Claims
1. A machine-to-machine communication platform, comprising: an interface configured to communicate data to and from a plurality of Internet based data acquisition devices; a storage device; instruction code storage; and a processor in communication with the interface, storage device and instruction code storage, wherein the instruction code storage stores instruction code for causing the processor to: store data communicated from one or more of the plurality of Internet based data acquisition devices to the storage device; convert at least some of the received data to a common format; analyze data communicated by one or more of the data acquisition devices in real-time; generate a visual representation of data acquired by one or more of the data acquisition devices in real-time; permit a user of the platform to associate a rule with one or more of the plurality of Internet based data acquisition devices; permit a user of the platform to define one or more new rules or manage one or more existing rules to control how data acquired by an associated data acquisition device is communicated from the associated data acquisition device to a third party system outside of the platform; and perform one or more actions according to the one or more rules.
2. The machine-to-machine communication platform according to claim 1, wherein the instruction code causes the processor to register one or more of the plurality of Internet based data acquisition devices with the machine-to-machine communication platform.
3. The machine-to-machine communication platform according to claim 1, wherein the actions performed include one or more of: transmitting an email to the third party system, transmitting an instant message to the third party system, and transmitting an alarm.
4. The machine-to-machine communication platform according to claim 1, wherein the plurality of Internet based data acquisition devices include one or more of: sensors, gateways, home automation devices, and home metering devices.
5. The machine-to-machine communication platform according to claim 1, wherein the data received from the plurality of Internet based data acquisition devices includes measurement data associated with measurements performed by the Internet based data acquisition devices.
6. The machine-to-machine communication platform of claim 1, wherein the instruction code causes the processor to communicate a message to a mobile device.
7. The machine-to-machine communication platform of claim 1, wherein the instruction code causes the processor to communicate to the third party system to trigger activation and/or implementation of a process at the third party system.
8. A method performed by a machine-to-machine communication platform for communicating information, the method comprising: communicating, through an interface of the machine-to-machine communication platform, data to and from a plurality of Internet based data acquisition devices; storing data communicated from one or more of the plurality of Internet based data acquisition devices to a storage device; converting at least some of the received data to a common format; analyzing data communicated by one or more of the data acquisition devices in real-time; generating a visual representation of the data acquired by one or more of the data acquisition devices in real-time; receiving information from a user of the machine-to-machine communication platform to associate a rule with one or more of the plurality of Internet based data acquisition devices; receiving information from a user of the machine-to-machine communication platform to define one or more new rules or manage one or more existing rules to control how data acquired by an associated data acquisition device is communicated from the associated data acquisition device to a third party system outside of the machine-to-machine communication platform; and performing one or more actions according to the one or more rules.
9. The method according to claim 8, further comprising registering one or more of the plurality of Internet based data acquisition devices with the machine-to-machine communication platform.
10. The method according to claim 8, wherein the actions performed include one or more of: transmitting an email to the third party system, transmitting an instant message to the third party system, and transmitting an alarm.
11. The method according to claim 8, wherein the plurality of Internet based data acquisition devices include one or more of: sensors, gateways, home automation devices, and home metering devices.
12. The method according to claim 8, wherein the data received from the plurality of Internet based data acquisition devices includes measurement data associated with measurements performed by the Internet based data acquisition devices.
13. The method according to claim 8, further comprising communicating a message to a mobile device.
14. The method according to claim 8, further comprising communicating to the third party system to trigger activation and/or implementation of a process at the third party system.
15. A non-transitory computer readable medium that stores instruction code for communicating information between machines, the instruction code being executable by a machine for causing the machine to perform acts comprising: communicating data to and from a plurality of Internet based data acquisition devices; storing data communicated from one or more of the plurality of Internet based data acquisition devices to a storage device; converting at least some of the received data to a common format; analyzing data communicated by one or more of the data acquisition devices in real-time; generating a visual representation of the data acquired by one or more of the data acquisition devices in real-time; receiving information from a user of the machine to associate a rule with one or more of the plurality of Internet based data acquisition devices; receiving information from a user of the machine to define one or more new rules or manage one or more existing rules to control how data acquired by an associated data acquisition device is communicated from the associated data acquisition device to a third party system outside of the machine; and performing one or more actions according to one or more rules.
16. The non-transitory computer readable medium according to claim 15, wherein the instruction code causes the machine to register one or more of the plurality of Internet based data acquisition devices with the machine.
17. The non-transitory computer readable medium according to claim 15, wherein the actions performed include one or more of: transmitting an email to the third party system, transmitting an instant message to the third party system, and transmitting an alarm.
18. The non-transitory computer readable medium according to claim 15, wherein the plurality of Internet based data acquisition devices include one or more of: sensors, gateways, home automation devices, and home metering devices.
19. The non-transitory computer readable medium according to claim 15, wherein the data received from the plurality of Internet based data acquisition devices includes measurement data associated with measurements performed by the Internet based data acquisition devices.
20. The non-transitory computer readable medium according to claim 15, wherein the instruction code causes the machine to communicate a message to a mobile device.
21. The machine-to-machine communication platform according to claim 1, wherein the instruction code causes the processor to permit a user of the platform to define one or more new rules by invoking an addRule service in an event handler.
22. The machine-to-machine communication platform according to claim 1, wherein the instruction code causes the processor to permit a user of the platform by calling services in an event handler to deactivate one or more existing rules by calling a deactiveRule service, add a new Action to one or more existing rules by calling an addAction service, or activate one or more existing rules by calling an activeRule service.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) The system may be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)
(32)
(33)
(34)
(35)
(36)
(37)
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
(46)
(47)
(48)
(49)
(50)
(51)
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
(52)
(53)
(54) Device management is a set of technologies, protocols and standards used to allow the remote management of devices 106. Users 112 or third parties 108 may use the device management functionality to update device firmware or operating systems, install applications, or fix bugs, using a wireline or wireless interface to the Platform 102. The device management functionality allows the configuration of the devices 106, including, as examples, configuring the devices for first time use, enabling features of the device, and disabling the features. The device management functionality also allows changes to be made to settings and parameters of the devices 106, provide for new software and/or bug fixes to be loaded on the devices, and provide firmware upgrades and lifecycle management of the devices. The device management functionality may be provided via a web portal or web service interfaces that allow third parties to perform device management operations.
(55) The device management functionality works in conjunction with one of the repositories 220, the a device repository 224, which contains, for each specific device 106, the configurable settings and the configuration XML which are used to configure the device 106. The device repository 224 manages the specific configurable XML and the Open Mobile Alliance (OMA) configuration XML. The device repository 224 is also able to store update packages used to upgrade the device firmware or software.
(56) Device monitoring functionality provides device diagnostics and fault management functions. The diagnostics and fault management not only refers to the hardware issues, but also encompasses other elements of the device 106, such as the SIM card, device hardware, and application modules which. The device diagnostics component of the device monitoring functionality is able to analyze log files, the presence of the device 106 on the network and the data regarding the status of the device. The fault management component evaluates predetermined rules and performs actions according to the rules. Examples of possible actions are: sending short messaging service messages (SMS) or emails to notify an event or an alarm to the user 112, third party service provider 108 or other interested entities; triggering a workflow; generating a real-time report on the status of the device 106; or other actions that may be defined by the predetermined rules. The fault management component of the device monitoring functionality allows a user 112 or the third party service provider 108 to configure the rules on the fly, and the actions work in conjunction with the alerting system 234. The alerting system 234 is a component of the Platform 102 which notifies alerts to the users 112 or third party service provider 108 through SMS, emails, and/or web-alerts. The users 112 or third parties 108 may display reports and alarms from a web portal. The reports may be chart reports, dashboards, or other reports. Some examples of information displayed by the reports are: number/percentage of device 106 in fault status and number/percentage of device 106 in stand-by status.
(57) Platform 102 also provides data capture functionality by providing functions to take data received from devices 106 and dispatch the data to third party service provider 108 or processing components of the Platform 102, or to store the data in a data repository 222. The data repository 222 may store detailed data received from the devices 106. Some examples of types of data stored are alarm and data regarding status of the device 106. Service operational data and/or image/video data are dispatched to third parties 108, vertical solutions 202 and are stored in their specific repositories is the set of repositories 220.
(58) The components of the Platform 102 may trace usages of various types to support the accounting functionality. The accounting functionality may be provided by a flow Business Process manager. The accounting functionality may also be provided by integrating with a third party accounting system. Examples of usages traced are usage of services, number of SMSs sent, number of notified events and amount of data traffic generated. The Platform 102 may be integrated with a metering system to provide support for the accounting functionality. The metering system may be a standalone component from the Platform 102 which may be invoked via Remote Method Invocation (RMI) or Simple Object Access Protocol (SOAP).
(59) The machine to machine platform 102 may comprise various logical components which implement the functionalities described in the preceding paragraphs. The vertical solution gateway 216 communicates with the orchestrator and business process manager 238 to allow communication between the rest of the Platform 102 and the vertical solutions 202.
(60) Third party gateway component 218 provides capabilities to perform inbound and outbound request authorization, authentication criteria management and request dispatching. This component provides web services and APIs that allow vertical solutions 202 and third parties 108 (and their customers) to perform all functionalities of the Platform 102 (for example, subscription/unsubscription of device on the Platform 102, activation/deactivation of services, configuration of device, data retry, check status of device, and metering). Web services and APIs are classified based on application domains. Each service hosted on the Platform 102 may be associated with an application domain. An application domain may be associated with many services. Application domains will be described in further detail below.
(61) Repositories 220 may include various repositories for storing data or configuration information used for the various components of the Platform 102. The repositories 220 may be implemented as a single database with a plurality of tables or may be implemented as separate databases for specific functions. Examples of repositories 220 include data repository 222, device repository 224 and the events repository 226. Data repository 222 manages the asset of the Platform 102, such as devices 106, their SIM cards and their configuration. Data repository 222 also supports the subscription and provisioning functionalities.
(62) Components of the common services components 228 provide functionalities which may be shared for hosing various services. Common services components 228 may include a location component 230, an event handler 232, an alerting system 234 and a device management component 236.
(63) The orchestrator and business process manager (Process Manager) 238 communicates directly or indirectly with all the components of the Platform 102 to orchestrate the functionalities of the Platform 102. Communication manager 240 receives and transforms messages from the devices 106 into messages which may be understood by various components of the Platform. The functionalities of the communications manager 240 also may be implemented in the external gateways 104, to which the devices 106 may be connected.
(64) The network enabler 256 may communicate with the communication manager 240 to allow the Platform 102 to connect to the telecommunications network or other networks on which the Platform 102 communicates with the devices 106. The network enabler 256 is the component responsible for enabling communications between the Platform 102 and the telecommunications network using various communications standards, such as SMSC, GGSN. LEA and Mail.
(65) The platform 102 may also be integrated with the metering system 258 for tracking usage data, while the web portals 260 and 262 allow third party users and administrators, respectively to access the functionalities provided by the Platform 102. Each web portal 260 and 262 includes two different areas. An administration area allows for third party administrators to administrate and maintain third party projects, devices 106 and data. A project is a logical group of devices 106. A device management area of the web portals 260 and 262 allows the third party users to upload new firmware or delta firmware, visualize the actual configuration of the device 106, and set new values for configuration parameters by directly inputting the values or by uploading a new XML configuration file.
(66) The communication manager 240 is a component responsible for communication between the devices 106 and the Platform 102 and between external gateways 104 and the Platform 102. The communication manager 240 allows the Platform 102 to communicate with the devices 106 using a common language independent from the particular device and specific for the application domain. In an embodiment, such common language may be a version of XML, a Machine to Machine (M2M) XML format. The translation to and from the M2M XML format is performed using Stylesheets. Using a Stylesheet, the communication manager 240 may translate messages received from devices 106 into the M2M XML format, and also translate the M2M XML message originating from the Platform 102 into a message which the recipient device 106 may understand. Support for a new device may be performed by inserting a new Stylesheet into the repositories 220.
(67) Device management component 236 is one of the common service components 228. The device management component 236 implements the device management functionality discussed above. This component is responsible for device management functionalities, including implementing any desired server specification (e.g., the Open Mobile Alliance Device Management OAM DM) for communicating with the devices 106.
(68) A device monitoring component 264, one of the vertical solutions 202, implements parts or all of the device monitoring functionality described above. This component provides the business logic and the functionalities to analyze the log errors from the devices 106, the presence of devices and data regarding the status of the devices. The fault management logic may utilize the event handler 232 and sends the alarms to the alerting system 234 and generates reports in real-time regarding the status of the devices 106. The third party service provider user may access a monitoring web console 266 to monitor and control selectable data, view any parameters as a trend graph and to configure, visualize and handle alarms.
(69) The event handler 232 is one of the common services 228, which manages events/alarms that the devices 106 send to the Platform 102 (external events) or events/alarms generated by the Platform 102 (internal events). The event handler 232 works in conjunction with the rules repository, which may be one of the repositories 220, to send triggers to the vertical solutions 202. The Alerting system 234 notifies the alerts to the user 112 and/or the third parties 108 via SMS, email or web-alerts. The location component 230 provides geographic information system functionalities, such as view map, geocoding, and tracking. This component also provides a map indicating the locations of projects and devices 106 on a monitor area of the monitoring web console 266.
(70) Metering system 258, web portals 260 and 262, and the web console 266 may be implemented in the Platform 102, stand alone systems integrated with the Platform 102, or stand alone third party solutions.
(71)
(72)
(73) A communication model implementing a protocol between the Platform 102 and the devices 106 may be provided. A specific library may be managed in order to provide support for devices not compliant with the communication model.
(74) In an embodiment of the communication model, messages communicated to and from the devices 106 and the Platform 102 may be classified based on their purposes. Table 1 shows the message types and the callers and the recipients identified for each message types.
(75) TABLE-US-00001 TABLE 1 MessageType Caller Recipient ConfigurationCommand Platform Device ConfigurationQuery Platform Device ConfigurationQuery Device Platform Event Device Platform ApplicationQuery Platform Device Acknowledge Platform Device Acknowledge Device Platform
(76) A message of MessageType ConfigurationCommand may be used to set up or update the value of a configuration parameter of a device 106. Depending on the application domain, messages of this MessageType could effectively become an application command. For example within the home automation context, in order to turn off all lights in an apartment, the Platform 102 could send a ConfigurationCommand for a parameter “Light Status” with the value “OFF_ALL”. Such message gives the command turn off for all apartment lights to the home automation device.
(77) A message of MessageType ConfigurationQuery may be used by the Platform 102 to request the current device configuration or vice versa.
(78) A message of MessageType Event may be used when the device 106 triggers a condition and sends relevant information to the Platform 106.
(79) A message of MessageType ApplicationQuery may be used by the Platform 102 to perform a data request to a device 106. The type or content of data requested depends on the definition of the application domain.
(80) A message of MessageType Acknowledge may be used to commit a previous communication.
(81) The application domain represents the classification of messages based on the application context ownership. In other words, the application domain identifies a family of messages. In this way, it is possible to authorize the dispatch of events coming from devices 106 only for those third parties 108 that have subscribed to the application domain to which the event belongs. For example, a monitoring service provider should be subscribed to the monitoring application domain before receiving monitoring events. Other examples of application domains are: vehicle tracking, security, home automation, vending machine management, remote metering (AMR/AMI, remote monitoring & control), remote health diagnostics and configuration. The domain configuration is a common domain used for configuration purposes. However, some configuration actions could be required only for a particular application domain.
(82) A Protocol Data Unit (PDU) may be part of the communication model which may be used for interfaces exposed by the platform 102 to the device 106 and vice versa. Each request/response message may include the PDU. A PDU may define the following:
(83) Request: set of parameters provided by the device 106 or the platform 102 which initiates the communication to the recipient. There are several types of requests as explained below in order to manage synchronous and asynchronous communication scenarios.
(84) Response: set of parameters provided by the recipient of a previous synchronous request.
(85) Table 2 shows an example of parameters for the “Requests” and the “Responses”:
(86) TABLE-US-00002 TABLE 2 Request Response requestType responseStatus caller conversationID Timestamp Payload Priority protocolVersion Expires Recipient conversatioID Payload protocol Version
(87) The following are examples of possible values for the parameter “requestType”:
(88) GET: used by the platform 102 or device 106 in order to request a resource to the recipient in a synchronous or in an asynchronous mode. If the physical channel does not support bidirectional channel, the communication is forced to be asynchronous. In some cases, if the asynchronous mode is not suitable for a business process, it could be assumed that the response is not required.
(89) POST: Used by the platform 102 or the device 106 to set or update the status of the recipient.
(90) Reply: Used in asynchronous scenarios in order to communicate the response to a previous request.
(91) Notify: Used when the caller wants to notify the availability of resource. Usually “Notify” will follow a GET request in order to obtain the resource.
(92) The physical channels of the communication model may be SMS or HTTP/HTTPS over GPRS. SMS is always used by the platform 102 when the Platform needs to initiate the communication with the device 106. SMS supports only asynchronous communications. HTTP/HTTPS over GPRS is used by the device 106 to communication triggered events but also is used by the Platform 102 to send responses to the devices upon previous requests.
(93) Table 3 shows examples of possible combinations between PDU, caller recipient, messageType, and the physical channel.
(94) TABLE-US-00003 TABLE 3 Physical PDU Caller MessageType Channel Recipient Async. POST Platform ConfigurationCommand SMS Device Async. GET Platform ConfigurationQuery SMS Device Async. GET Platform ApplicationQuery SMS Device Sync. Platform Acknowledge HTTPs Device Response Async. Notify Platform ConfigurationCommand SMS Device Sync. Reply Device Acknowledge HTTPs Platform Sync./Async Device ConfigurationQuery HTTPs Platform GET Sync. POST Device Event HTTPs Platform Sync. Reply Device Event HTTPs Platform
(95) Referring back to
(96)
(97) The task of the event generator 502 component is to verify, through predefined rules and questioning selected sources of information available (in databases, responses from web services, and other sources), whether or not to generate an alarm.
(98) The role of the event manager 504 is to manage the life cycle of events. Event repository 226 stores all the events, even those already closed. The rules repository 506 stores all the default rules. Data repository 222 may be used as the data dictionary that the event handler 232 may reference during the assessment of the rules contained in the rules repository 506. These data can equally be data in a database, responses to web services invocations internal or external to the platform, etc. The rules editor 508 is an interface, made available by the Platform 102 for defining new rules and the managing existing rules. The rules editor 508, normally provided by commercial BRMS, provides interfaces for the definition and population of the rules repository 224. Through interfaces (web services) made available by the Platform 102 in the event handler 232, the event manager front end 510 provides third party service provider users the ability to see in detail the all the events and the possibility to manage the life cycle (create new event, closing event, and other parts of the life cycle) of the events. For example, part of the event manager front end 510 could be a graphical user interface (GUI) available to an operator of a control room to view the details of an event and ask to close an event the system safety has been verified.
(99) As examples, an event may include the following attributes: Event id Event type Event status Creation method (internal/external) Event creation timestamp Last status change timestamp Parent event id (optional) Event owner id (component/operator) Event parameters
(100) Among the main objectives of the event manager 232 is to handle the event: to decide what action to take once an event is created and in what order (event-reaction workflow). The event-reaction will be undertaken on the basis of the attributes of the event, with particular reference to the type of event and subject to the particular value assumed by the parameters that accompany it (event parameters). The actions 512 performed in response to the event may include sending emails, sending SMS, invoking web services, and creating a child event.
(101)
(102) The device management component 236 implementing the custom solution supports the Firmware Over-The-Air (FOTA) process. The solution is also compliant to the OMA specifications. FOTA is a process that allows embedded software to be updated wirelessly, anywhere and at any time. A firmware includes all the software which enables a device operational. Unlike regular software, firmware is not customizable by the end user using the device.
(103) The device management component 236 further includes an OMA-DM component 602, OMA-FUMO component 604, a delta generator 606 and an update agent 608. The OMD-DM 602, OMA-FUMO (Open Mobile Alliance—Firmware Update Management Object) 604 and the delta generator 606 components reside on the Platform 102. The OMA-DM component 602 is a component that implements the OMA DM 1.2 specification. The OMA DM 1.2 specification is a device management protocol for management of all small devices over the air. The OMA-FUMO component 604 is a component that implements the OMA FUMO 1.0 specification for updating firmware. The delta generator 606 may be software which compares two firmware versions and generates a delta package containing only the differences between the two firmware versions. The update agent 608 is a client side component which resides in firmware of devices 106 and applies the actual update to the firmware. The delta generator 606 and update agent 608 may be proprietary to each device, but are compliant to the OMA specifications. An OMA-DM client 610 may also be provided on the device 106 for communicating with the components of the device manager component 236 residing on the Platform 102. All the components of the device management component 236 may be implemented to support the linux operating system (OS).
(104) The FOTA update cycle may generally follow a four stage process: 1) generating the firmware update (delta package); 2) transmitting and submitting the update to a firmware management server; 3) downloading the firmware to the device 106; and 4) updating the device by the update agent 608. The firmware management server may be the DMA-FUMO component 604. The device management component 236 may implement stages 2, 3 and 4 to support the linux OS. The device management 236 may also integrate proprietary solutions to implement support for all the stages 1-4.
(105)
(106) The device monitoring component 264 may implement the device monitoring functionality described above. The device monitoring component 264 verifies status, performance, fault condition and diagnostics analysis of the devices 106 in order to avoid/reduce business service outages/failures or in order to fulfill service level agreements between the service provider 108 and a user 112. The device monitoring component 264 allows the service provider 108 to be notified of device failures via emails or SMS, or through a web console 266 displaying a list of failed devices. The web console 266 may display the failed devices in a dashboard. The web console 266 may be part of the web portal 260 or 262.
(107) The device monitoring component 264 may support trouble shooting of failed devices 106. To that end, the device monitoring component 264 may analyze separately each element of a device, such as the SIM card, the device hardware and firmware, and application modules. Other individual elements of a device 106 may be monitored individually as well.
(108) Information monitored by the device monitoring component 264 may include status, such as OK, KO, ON, OFF, Stand by, Active, Not Active, or Not Defined. Network channel use, network presence, working condition, last configuration update date, and last reset (reboot) date may also be monitored. Network channel usage for all communications interfaces including SMS and GPRS may be monitored. Network presence indicates the presence of a SIM on an MNO network, such as GSM or GPRS. Working condition indicates whether or not the device is equipped with sensors to discover critical environment conditions such as temperature, humidity, or low power supply or other conditions. The monitored information may also include performance information such as average CPU usage and memory usage.
(109) The device monitoring component 264 may also aggregate and report visualization of the monitored information. A user 108 or a third party service provider 108 may group all its own devices 106 or a subset of them by the status information. The user 112 or the third party service provider 108 may also group all is devices 106 by client, VAS, project, or site.
(110) The device monitoring component 264 may further provide for KPI management and configuration of SLA such as real time graphical representation of device performance and tracking of fault condition in order to manage service levels. The component 264 further supports polling, trapping and real time request mechanisms. Polling refers to performing a scheduled query by the Platform 102 to the device 106. Trapping refers to triggering events by messages from the devices 106 based on predefined conditions, configurations or rules. The events also may be triggered by the device 106. Real time request refers to a user 112 or a third party service provider 108 making a real time monitoring request for all monitored entities. The real time request may be made through the web portals 260 or 262. The monitored entities may include any devices 106.
(111) The device monitoring component 264 may also provide message notification of predefined events via SMS or email. The device 264 may further provide a high-level, business view of monitored devices.
(112)
(113)
(114)
(115)
(116) RequestType: POST
(117) Caller: DCM
(118) Payload:
(119) Domain: Configuration
(120) Parameters: <array of ConfigParam>
(121) MessageType: ConfiguraitonCommand.Activation
(122) Status: ON (for all domain associated o that serviceID).
(123) Afterwards, the process ends (918).
(124)
(125) RequestType: POST
(126) Caller: DCM
(127) Payload:
(128) Domain: Configuration
(129) Parameters: null
(130) MessageType: ConfiguraitonCommand.Deactivation
(131) Status: OFF (for all domain associated o that serviceID).
(132) Afterwards, the process ends (1018).
(133)
(134) RequestType: POST
(135) Caller: DCM
(136) Payload:
(137) Domain: Configuration (or Application, if the configuration is a command within a specific application domain)
(138) Parameters: <array of ConfigParam>
(139) MessageType: ConfiguraitonCommand.Configuration
(140) Status: ON (for all domain associated o that serviceID).
(141) Afterwards, the process ends (1118).
(142)
(143) RequestType: POST
(144) Caller: DCM
(145) Payload:
(146) Domain: Configuration
(147) Parameters: <array of ConfigParam>
(148) MessageType: ConfigurationCommand.Configuration
(149) Status: ON (for all domain associated o that serviceID).
(150) Afterwards, the process ends (1218).
(151)
(152) Payload:
(153) Domain: <Configuration>
(154) MessageType: ConfigurationQuery
(155) Target: deviceID
(156) If all the required parameters are provided, the Process Manager 238 determines whether or not the user 112 or the third party service provider 108 is authorized to request configuration (1306). If the required parameters are not provided, the Process Manager 238 notifies an error (1308) and the process ends (1312). At step 1306, if the user 112 or the third party service provider 108 is not authorized, the Process Manager 238 notifies an error (1308) and the process ends (1312). If the user 112 or the third party service provider 108 is authorized, the Process Manager 238 sends a ConfigurationQuery message to the device 106 corresponding to the deviceID (1310). The message may be sent using the sendRequest asynchronous interface via SMS, with the following parameters:
(157) RequestType: GET
(158) Caller: <serviceProvider ID or Service Provider URL>
(159) Payload:
(160) Domain: Configuration
(161) MessageType: ConfigurationQuery
(162) ConversationID: <ConversationID>
(163) Afterwards, the process ends (1312).
(164)
(165) sendRequest(
(166) RequestType: GET
(167) Caller: <deviceID>
(168) Payload:
(169) Domain: Configuration
(170) MessageType: ConfigurationQuery
(171) . . . )
(172) The Platform 102 receives the request, processes the request, and retrieves the requested configuration (1404). If all the required parameters are provided, the Process Manager 238 determines whether or not the deviceID exists in the device repository 224 (1406). If the required parameters are not provided, the Process Manager 238 notifies an error (1408) and the process ends (1412). At step 1406, if the deviceID does not exist in the device repository 224, the Process Manager 238 notifies an error (1408) and the process ends (1412). If the deviceID exists, the Process Manager 238 sends a Configuration message to the device 106 corresponding to the deviceID (1410). The message may be sent using the sendRequest synchronous interface, with the following parameters:
(173) ResponseStatus: OK
(174) RequestType: GET
(175) Payload:
(176) Domain: Configuration
(177) Parameters: <array of ConfigParam>
(178) MessageType: ConfigurationCommand.Activation
(179) Status: ON (for all domain associated to that service ID)
(180) Afterwards, the process ends (1412).
(181)
(182)
(183)
(184) RequestType: POST
(185) Caller: <deviceID>
(186) Recipient: <recipient url>
(187) Payload:
(188) Domain: <application domain>
(189) MessageType: Event <ID>
(190) Data: <data>
(191) A device 106 may also send back a requested data (1704). Since SMS is not a bidirectional channel, the Device 106 may initiate a new communication to the Platform 102, using the sendRequest interface with the following parameters:
(192) RequestType: REPLY
(193) Caller: <deviceID>
(194) Recipient: <recipient url>
(195) Payload:
(196) Domain: <application domain>
(197) MessageType: Event <ID>
(198) Data: <data>
(199) ConversationID: <conversation id>
(200) The Platform 102 receives the messages from the device from steps 1702 or 1704 (1706), and determines whether or not required parameters are provided (1708). If the required parameters are not provided, the Platform 102 sends a NACK to the device 106 using the sendResponse interface with the following parameters (1710):
(201) ResponseStatus: KO
(202) Payload:
(203) MessageType: Acknowledge
(204) Subsequently the process ends (1722). If all the required parameters are provided, the Process Manager 238 determines whether or not a recipient is provided with the request (1712). If a recipient is provided, the Platform 102 forwards the request to the recipient using the notifyEvent interface (1714). Next, the Platform 102 sends an ACK signal to the device 106 using the sendResponse interface, along with the following parameters (1716):
(205) ResponseStatus: OK
(206) Payload:
(207) MessageType: Acknowledge
(208) Next, the process ends (1722). At step 1712, if no recipient is provided, the Platform 102 parses the request and dispatches the event to all subscribed service providers (including user 112 and/or third party service provider 108), using the notifyEvent interface (1718). The dispatch depends on the domain to which the triggered event belongs. Next, <data> is stored in the data repository 222, or other repositories 220 (1720). Afterwards, the Platform 102 sends an ACK signal to the device 106 using the sendResponse interface, along with the following parameters (1716):
(209) ResponseStatus: OK
(210) Payload:
(211) MessageType: Acknowledge
(212) Next, the process ends (1722).
(213)
(214) Payload:
(215) Domain: <application domain>
(216) MessageType:
(217) ApplicationQuery: <ID>
(218) If all the required parameters are provided, the Process Manager 238 determines whether or not the user 112 or the third party service provider 108 is subscribed to the domain to which the requested resource belongs (1806). If the required parameters are not provided, the Process Manager 238 notifies an error (1808) and the process ends (1812). At step 1806, if the user 112 or the third party service provider 108 is not subscribed to the domain to which the requested resource belongs, then the Process Manager 238 notifies an error (1808) and the process ends (1812). If the user 112 or the third party service provider 108 is subscribed to the domain, then the Process Manager 238 sends to the devices 106 the ApplicationQuery message using the sendRequest asynchronous interface via SMS (1810). The message is sent with the following parameters:
(219) RequestType: GET
(220) Caller: <serviceProviderID or Service Provider url>
(221) Payload:
(222) Domain: <application domain>
(223) MessageType:
(224) ApplicationQuery: <ID>
(225) ConversationID: <ConversationID>
(226) Next, the process ends (1812).
(227)
(228) Payload:
(229) Domain: Configuration
(230) MessageType: ConfigurationCommand
(231) Configuration Parameters: download firmware (ON)
(232) Device Model: <deviceModel>
(233) Firmware url: <url>
(234) If all the required parameters are provided, the Process Manager 238 determines whether or not the devices of the provided device model exists (1906). The determination may be done by searching the device repository 224. If the required parameters are not provided, the Process Manager 238 notifies an error (1908) and the process ends (1912). At step 1906, if devices of the provided device model do not exist, then the Process Manager 238 notifies an error (1908) and the process ends (1912). If such device exists, then the Process Manager 238 sends to the devices 106 the ConfigurationCommand message using the sendRequest asynchronous interface via SMS (1910). The message is sent with the following parameters:
(235) RequestType: Notify
(236) Caller: DCM
(237) Payload:
(238) Domain: Configuration
(239) MessageType: ConfigurationCommand
(240) ConfParameters:download firmware (ON)
(241) ConversationID: <ConversationID>
(242) Firmware url: <url>
(243) Next, the process ends (1912).
(244) Upon receiving a download firmware notify message from the Platform 102, a device 106 may connect to a provided url to initiate downloading of firmware (1914). The platform 102 may receive the download request from the device 106 and processes the request (1916). Next the Platform 102 determines whether or not the firmware download package exists and whether or not the device requesting the download is authorized (1918). If no package is available for download or if the device is not authorized, the Platform 102 notifies an error (1920) and the process ends (1924). If a package is available and the device is authorized, then the download begins (1922). If the download is successful, then the process ends (1924). If the download is not successful, then the Platform 102 notifies an error (1920) and the process ends (1924).
(245)
(246) A device 106 may trigger a fault condition and initiate communication to a monitoring service provider (2008). Next, Application Communication—Event Dispatch process is executed in order to dispatch to the device 106 status data which were previously requested to a service provider (2010). Next, data is stored into a monitoring repository which may be one of the repositories 220 (2012). Data stored in the monitoring repository may be data received from the devices 106 in response to the device monitoring request or data sent to the device in response to a fault condition. Then, the event handler component 232, based on predefined rules, manages the status information captured from the devices 106 (2014). The event handler 232 communicates with the alerting component 234 in order to present the fault conditions to the monitoring service provider. Three exemplary channels of communicating the fault conditions are: displaying on the web console 266, sending SMS messages to a distribution list, and mailing to a distribution list. In the case of using the web console 266, the web console is refreshed to display the fault condition (2016), and the process ends (2018).
(247) The various interfaces described above are exposed and used by the Platform 102 to communicate with the devices 106 or vertical solutions 202. The interfaces may be asynchronous or synchronous interfaces such as SMS, HTTP, SOAP, or SOAP with call back.
(248) The communication manager 240 is described in further detail below.
(249) Devices 106 interacting with the platform 102 may send their messages/samplings to communication manager 240. The communication manager 240 may expose on /M2MWEB/receiver the com.company.amos.m2m.dcm.web.StandardDeviceServlet servlet. Once a message is received by the servlet, then an appropriate adapter is selected to extract data from the message and produce a device message 406. Adapters may be stored in a M2M_DCM repository, which may be one of repositories 220. The adaptors may be stored in the M2M_DCM repository according to the following hierarchy of categorization:
(250) Device.fwdarw.Model.fwdarw.Model_adaptors.fwdarw.Adapters (by communication channel).
(251) Once the device message 406 is produced, then the message is transformed by a transformer 244 into a standard, high-abstraction level service message 408 which may be understood by rest of the components of the Platform 102. The transformer may be stored in the M2M_DCM repository, and may be stored in the M2M_DCM.DeviceToSvcMsgTransformer table. A suitable transformer is selected by matching the nameSpaceURI parameter contained in the message and the M2M_DCM.DeviceToSvcMsgTransformer.expression field. The message 406 is transformed into a service message 408 by invoking the transform( ) method of the selected transformer. Once the message is transformed, the transformed service message 408 may be sent to the Process Manager 238 for delivery to appropriate components of the Platform 102. The application manager 246 described with reference to
(252) An exemplary process for providing support for a new device model named MyNewModel by manufacturer DUMMY is provided below.
(253) First, the M2M_DCM repository is configured. The record (DUMMY) is inserted into M2M_DCM.Manufacturer table. Next, the record (N, MyNewModel, DUMMY) is inserted into M2M_DCM.Model table, where N is the key of the M2M_DCM.Model table. N is a progressive number. In this example, the value 4 will be used. Then, the record (4,1) is inserted into the M2M_DCM.Model_adapter table. 1 is the key of one adapter specified in the M2M_DCM.Adapters table.
(254) A new transformer is also needed. The purpose of a transformer is to transform the message received from a device 106 into a standard message to be sent to the Process Manager 238 or other components of the Platform 102. Every transformer extends directly or indirectly from the com.company.amos.m2m.dcm.msgprocessing.MessageTransformer class.
(255) In case of an XSL transformer, an example of its implementation is com.company.amos.m2m.dcm.msgprocessing.impl.AbstractXslTransformer. AbstractXslTransformer is an abstract class and it is extended by implementing the getXslt( ) method that returns the path of XSLT transformer file. The transformer produces, in the output, an XML which is validated against the XSD file dcmMessage.xsd shown below in Table 4:
(256) TABLE-US-00004 TABLE 4 <?xml version=″1.0″ encoding=″UTF-8″?> <xs:schema xmlns:xs=″http://www.w3.org/2001/XMLSchema″ elementFormDefault=″qualified″> <xs:element name=″DCMDOCUMENT″> <xs:complexType> <xs:sequence> <xs:element maxOccurs=″unbounded″ ref=″EVENT″/> </xs:sequence> <xs:attribute name=″version″ use=″optional″ type=″xs:string″/> </xs:complexType> </xs:element> <xs:element name=″EVENT″> <xs:complexType> <xs:sequence> <xs:element ref=″TIMESTAMP″ minOccurs=″1″ maxOccurs=″1″/> <xs:element ref=″DEVICE″ minOccurs=″1″ maxOccurs=″1″/> <xs:element ref=″TRANSACTION_ID″ minOccurs=″1″ maxOccurs=″1″/> <xs:element ref=″TRIGGER″ minOccurs=″1″ maxOccurs=″1″/> <xs:element maxOccurs=″unbounded″ ref=″RAW_DATA″/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=″TIMESTAMP″ type=″xs:dateTime″/> <xs:element name=″DEVICE″ type=″ID″/> <xs:element name=″TRANSACTION_ID″ type=″xs:string″/> <xs:element name=″TRIGGER″> <xs:complexType> <xs:complexContent> <xs:extension base=″ID″> <xs:sequence> <xs:element minOccurs=″0″ ref=″DETAIL″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name=″DETAIL″ type=″xs:string″/> <xs:element name=″RAW_DATA″> <xs:complexType> <xs:sequence> <xs:element maxOccurs=″unbounded″ ref=″PARAM″/> </xs:sequence> <xs:attribute name=″impl″ use=″optional″ type=″xs:string″/> <xs:attribute name=″type″ use=″required″ type=″xs:string″/> </xs:complexType> </xs:element> <xs:element name=″PARAM″> <xs:complexType> <xs:attribute name=″name″ use=″required″ type=″xs:string″/> <xs:attribute name=″value″ use=″required″ type=″xs:string″/> <xs:attribute name=″javatype″ use=″required″ type=″xs:string″/> </xs:complexType> </xs:element> <xs:complexType name=″ID″> <xs:sequence> <xs:element ref=″ID″ minOccurs=″1″ maxOccurs=″1″/> </xs:sequence> </xs:complexType> <xs:element name=″ID″ type=″xs:string″/> </xs:schema>
(257) Next, a new record is inserted into the M2M_DCM.DeviceToSvcMsgTransformer table. For example, if the new name of the transformer class is com.company.amos.m2m.dcm.msgprocessing.impl.MyNewXslTransformer, and the root node of XML to be transformed is intercepted by XPath Query //:dummy-service[@domain=‘sampling’], then the record (//:dummy-service[@domain=‘sampling’], com.company.amos.m2m.dcm.msgprocessing.impl.MyNewXslTransformer) is inserted into the M2m_DCM.DeviceToSvcMsgTransformer table.
(258) To completely support a new device type in the Platform 102, some configuration has to be executed also on the Process Manager 238 component:
(259) insert into the M2M_AIB.device_type table the new device type,
(260) insert into the M2M_AIB.repository table appropriate configuration, and
(261) insert into the M2M_AIB.repository_group association between repository and groups.
(262) The M2M_AIB database may be one of the repositories 220 which may store configuration information for the Platform 102.
(263) The Platform 102 may store data sent from devices in dedicated tables of repositories such as data repository 222. The M2M_AIB database may be one such repository. Tables for storing data has a primary key field named id_base defined as:
(264) TABLE-US-00005 PRIMARY KEY (‘id_base’), KEY ‘fk_1 _base1’ (‘id_base’), CONSTRAINT ‘ fk_1 _base1’ FOREIGN KEY (‘id_base’) REFERENCES ‘base’ (‘id_base’)
(265)
(266) TABLE-US-00006 CREATE TABLE ‘dummy’ ( ‘id_base’ int(11) NOT NULL, ‘field_1’ varchar(255) default NULL, ‘field_2’ varchar(255) default NULL, PRIMARY KEY (‘id_base’), KEY ‘fk_home_metering_base1’ (‘id_base’), CONSTRAINT ‘fk_home_metering_base1’ FOREIGN KEY (‘id_base’) REFERENCES ‘base’ (‘id_base’) ON DELETE NO ACTION ONUPDATE NO ACTION ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
(267) The Platform 102 may use JPA (Java Persistence API) to manage data access. M2M-DAL module manages access to M2M_AIB DB.
(268) Once the data collection table has been created, a POJO class with JPA annotations is created in the package com.company.amos.m2m.dal.entity.
(269) The Platform 102 exposes data access as web services. To perform that task, particularly to identify POJO attributes to return, a custom annotation is used: com.company.amos.m2m.dal.entity.Exclude. @Exclude annotation is set on methods of the POJO that doesn't return the value of one of the attributes we have to expose.
(270) For the table dummy the annotated POJO may be implemented as shown in Table 5:
(271) TABLE-US-00007 TABLE 5 @Entity @Table(name = ″dummy″) public class Dummy implements java.io.Serializable { private static final long serialVersionUID = −8228360678364527411L; private int idBase; private Base base; private String field1; private String field2; public Dummy( ){ } public Dummy(Base base) { this.base = base; } public Dummy(Base base, String field1, String field2) { this.base = base; this.field1 = field1; this.field2 = field2; } @GenericGenerator(name = ″generator″, strategy = ″foreign″, parameters = @Parameter(name = ″property″, value = ″base″)) @Id @GeneratedValue(generator = ″generator″) @Column(name = ″id_base″, unique = true, nullable = false) @Exclude public int getIdBase( ) { return this.idBase; } @Exclude public void setIdBase(int idBase) { this.idBase = idBase; } @OneToOne(fetch = FetchType.LAZY) @PrimaryKeyJoinColumn @Exclude public Base getBase( ) { return this.base; } @Exclude public void setBase(Base base) { this.base = base; } @Column(name = ″field_1″, length = 255) public String getField1( ) { return field1; } @Exclude public void setField1(String field1) { this.field1 = field1; } @Column(name = ″field_2″, length = 255) public String getField2( ) { return field2; } @Exclude public void setField2(String field2) { this.field2 = field2; } }
(272) The details of the event handler 232 are further described below.
(273) A third party service provider 108 or a user 112 may access the event handler 232 by calling the webservices interface exposed by the Platform 102 through the third party gateway 218. The event handler manages and processes events by using rules, actions and functions.
(274) A Rule is a logical expression characterized by (customerId, serviceId, deviceId) and a set of associated Actions. The third party service provider 108 or the user 112 can associate a Rule to one or more device 106. A Rule can have one or more Actions associated with it.
(275) The logical expression must be provisioned by a third party service provider 108 or a user 112 and can be composed of zero or more Functions.
(276) A Function is a complex logical expression provided by event handler 232. For each service hosted by the Platform 102 exists a set of Field with which a third party service provider 108 or a user 112 may compose a logical expression. A Field is an entity characterizing the associated Service. If logical expression evaluation is positive than the set of Actions associated to specified Rule is executed.
(277) An Action is a task provided by the event handler 232 and can be associated to zero or N input Parameter.
(278) Logical Expression
(279) Logical expression can be composed of logical operators, Fields, Functions. Fields can be retrieved by findFields service. Functions can be retrieved by findFunctions service.
(280) In a logical expression a field is expressed by syntax ${fieldName} where fieldName is the name of field. In a logical expression a function can be expressed by syntax #functionName(input1, input2) where functionName is the name of the function and input1, input2 are input parameters of the function.
(281) Table 6 shows some examples of logical expressions:
(282) TABLE-US-00008 TABLE 6 Description Rule if checkStatus is TRUE then execute actions ${checkstatus} == true if a sampling is received then execute actions ${baseid} if the field temperature of a sampling is greater ${temperature} > 30 than 30 degrees then execute actions
(283) Action
(284) An Action is a task provided by the event handler 232 and can be associated with zero or N input Parameters.
(285) A list of available Actions is provided by the findActionAndParamiters service.
(286) Rule
(287) A Rule is a logical expression characterized by (customerId, serviceId, deviceId) and a set of associated Actions. A third party service provider 108 or a user 112 can associate a Rule with one or more Devices. A Rule can have one or more Actions associated.
(288) To create a new rule, a third party service provider 108 or a user 112 can invoke the addRule service.
(289) Once a rule is created, the third party service provider 108 or the user 112 may: a. modify associated logical expression by calling modifyRuleExpression service, b. deactivate the rule by calling deactiveRule service, c. add a new Action by calling addActionService, or d. activate the rule by calling activeRule service.
(290) Table 7 shows examples of XML messages that are exchanged between the Platform 102 and the devices 106 or external gateways 104.
(291) TABLE-US-00009 TABLE 7 <?xml version=″1.0″ encoding=″UTF-8″?> <home-metering domain=″sampling″ xmlns=″http://www.domotica.com″>
<event id=″SAMPLING″ detail=″″> <timestamp>2010-01-13T12:50:00.000</timestamp> <senderMacAddress protocol=″IEEE″>008098E91FA2</senderMacAddress> <consumption unit=″kWh″>0.483</consumption> <voltage unit=″V″>111.9</voltage> <current unit=″A″>0.055</current> </event>
<event id=″SAMPLING″ detail=″″> <timestamp>2010-01-13T12:51:00.000</timestamp> <senderMacAddress protocol=″IEEE″>008098E91FA2</senderMacAddress> <consumption unit=″kWh″>0.483</consumption> <voltage unit=″V″>222.9</voltage> <current unit=″A″>0.078</current> </event>
<event id=″SAMPLING″ detail=″″> <timestamp>2010-01-13T12:52:00.000</timestamp> <senderMacAddress protocol=″IEEE″>008098E91FA2</senderMacAddress> <consumption unit=″kWh″>0.583</consumption> <voltage unit=″V″>333.9</voltage> <current unit=″A″>0.078</current> </event> </home-metering> <?xml version=″1.0″ encoding=″UTF-8″ ?> - <home-metering domain=″sampling″ xmlns=″http://www.domotica.com″> - <event id=″SAMPLING″ detail=″″> <timestamp>2010-01-11T12:50:00.000</timestamp> <senderMacAddress protocol=″IEEE″>333</senderMacAddress> <presence>1</presence> </event> </home-metering> <?xml version=″1.0″ encoding=″UTF-8″ standalone=″no″ ?> - <home-metering xmlns=″http://www.domotica.com″ domain=″sampling″> - <event detail=″″ id=″SAMPLING″> <timestamp>2009-11-18T14:46:37.093</timestamp> <senderMacAddress protocol=″IEEE″>333L</senderMacAddress> <lightLevel unit=″LUM″>16.0</lightLevel> </event> - <event detail=″″ id=″SAMPLING″> <timestamp>2009-11-18T14:46:39.062</timestamp> <senderMacAddress protocol=″IEEE″>333T</senderMacAddress> <temperature unit=″C″>31.5</temperature> </event> - <event detail=″″ id=″SAMPLING″> <timestamp>2009-11-18T14:46:39.171</timestamp> <senderMacAddress protocol=″IEEE″>333H</senderMacAddress> <humidity unit=″%″>39.3</humidity> </event> </home-metering>
(292) Device Map
(293) The Platform 102 may create and maintain a device map for keeping track of all the devices 106 in communication with the Platform for efficient management of the devices. The device map may identify the devices in communication with the Platform 102. For each identified device 106, the device map may indicate the channels the device uses to communicate with the platform 102, and whether the device acts only as a sensor which is only able to transmit information to the Platform, whether the device may only receive commands from the Platform, or whether the device may receive commands and act as a sensor. The device map may also contain other information which may be used for managing the devices 106. The device map may be stored in one of the repositories 220, such as the device repository 224.
(294) The Platform may receive the information necessary to populate the device map directly from the devices 106. The Platform 102 also may receive the necessary information from the external gateways 104, which collects the information from the devices 106 connected to itself, and submits the collected information to the Platform. In one embodiment, rather than just relaying the information, the external gateways 104 may create a device map of all the devices 106 connected to itself and forward the map to the Platform 102, which in turn aggregates the maps received from other external gateways to create a complete device map of all the devices 106 connected to the Platform.
(295) Web Services
(296) Third party gateway component 218 provides a web services interface that specifies the services exposed to 3rd parties. In one implementation, the link between the Web services and external systems of the third party gateway component 218 is simple object access protocol (SOAP) over HTTPS/1.1 or SOAP over HTTP/1.1. HTTPS or HTTP may be used as the transport protocol for the SOAP messages. Within a single HTTPS/HTTP connection, request and response messages may operate in a synchronous mode such that SOAP requests are made by Web Service client applications which are then processed by Web Service applications and an appropriate SOAP response is returned. The client making the request may wait until a response has been received before sending another request. Multiple parallel HTTPS/HTTP connections may exist for a Web Service enabling multiple requests to be processed concurrently.
(297) In one implementation, external systems connecting to the third party gateway component 218 Web Services are authenticated using SSL client certificates. Application level username/password combination may be used as another layer of customer authentication and this application level authentication may be used in particular for to authenticate internal systems. The external systems connecting to the third party gateway component 218 may be systems operated by the third party service provider 108 or user 112.
(298) The third party gateway component 218 Web services include a data access Web Service that provides methods to manage and monitor devices. In particular, the methods of the data access Web Service allow extraction of information about executed on devices, such as the commands remove, replace, put, configure, and events related to devices such as presence and power On/Off events.
(299)
(300) The data access Web service exposes methods including: findCommandByDeviceId; findEventByDeviceId; findEventDetail; and findEventDetailsByDeviceId.
(301) Table 8 shows an example findCommandByDeviceId request message for the findCommandByDeviceId method which retrieves a command list for a specified device and parameters.
(302) TABLE-US-00010 TABLE 8 findCommandByDeviceId Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION commandType String N 30 used to identify the type of operation on a device, a service or in general on an event deviceId String Y 30 the identifier of a specific device fromDate dateTime N used to extract a command list from a specific date status String Y 30 indicates the actual state of a device (Provisioned, active etc.) toDate dateTime N used to extract a command list until a specific date transactionId string Y 255 indicates a transaction identifier inside system 100
(303) Table 9 shows an example findCommandByDeviceId response message for the findCommandByDeviceId method.
(304) TABLE-US-00011 TABLE 9 findCommandByDeviceId Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description of the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error) commandId int N 11 identifier of the specific command found by the request commandType String N 30 describes the type of command found by the request lastDate dateTime N Most recent date on which the command was executed status String N 30 The field contains the result of the specific command
(305) Table 10 shows an example findEventByDeviceId request message for the findEventByDeviceId method which retrieves an event list for a specified device and parameters.
(306) TABLE-US-00012 TABLE 10 findEventByDeviceId Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION deviceId String Y 30 the identifier of a specific device eventType String N 50 Identifier of an event fromDate dateTime N used to extract a command list from a specific date toDate dateTime N used to extract a command list until a specific date transactionId string Y 255 The field indicates a transaction identifier inside M2M system
(307) Table 11 shows an example findEventByDeviceId response message for the findEventByDeviceId method.
(308) TABLE-US-00013 TABLE 11 findEventByDeviceId Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error) eventId int N 11 the identifier of the specific event found by the request commandType String N 30 describes the type of command found by the request eventType String N 30 describes the type of event found by the request lastDate dateTime N Most recent date on which the event was verified
(309) Table 12 shows an example findeventDetail request message for the findeventDetail method which retrieves an event details list for a specified device and parameters.
(310) TABLE-US-00014 TABLE 12 findeventDetail Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION eventId String N 30 the identifier of a specific event transactionId String Y indicates a transaction identifier inside the system 100
(311) Table 13 shows an example findeventDetail response message for the findeventDetail method.
(312) TABLE-US-00015 TABLE 13 findeventDetail Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error) name String N 50 The field is the name of a parameter configuration value String N 50 The field is the value of a parameter configuration
(313) Table 14 shows an example findEventDetailByDeviceId request message for the findEventDetailByDeviceId method which retrieves an event details list for a specified device ID.
(314) TABLE-US-00016 TABLE 14 findEventDetailByDeviceId Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION deviceId String Y 30 the identifier of a specific device eventType String N 50 Identifier of an event fromDate dateTime N used to extract a command list from a specific date toDate dateTime N The field is used to extract a command list until a specific date transactionId string Y 255 The field indicates a transaction identifier inside M2M system
(315) Table 15 shows an example findEventDetailByDeviceId response message for the findEventDetailByDeviceId method.
(316) TABLE-US-00017 TABLE 15 findEventDetailByDeviceId Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error) name String N 50 the name of a parameter configuration value String N 50 the value of a parameter configuration
(317) Third party gateway component 218 provides a device manager Web service.
(318) The device manager Web service provides methods to manage devices and provision new devices (e.g., configuration of the device, and enabling and disabling features), configure devices (e.g., changes to settings and parameters of the device), and remote management of devices (e.g., remove/replace a device), and activating a service. The exposed methods from the device manager Web service include: activate; checkStatus; configure; configureByDetails; deactivate; insertDevice; removeDevice; and replaceDevice.
(319) Table 16 shows an example activate request message for the activate method which activates a service for a specified device.
(320) TABLE-US-00018 TABLE 16 Activate Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION configurationId int N 11 identifier of an existing configuration customerId String Y 30 identifier of specific customer deviceId String Y 30 identifier of specific device serviceId int Y 11 identifier of specific service transactionId string Y 255 indicates a transaction identifier inside the system 100
(321) Table 17 shows an example activate response message for the activate method.
(322) TABLE-US-00019 TABLE 17 Activate Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(323) Table 18 shows an example checkStatus request message for the checkStatus method which sends a checkStatus request to a specified device.
(324) TABLE-US-00020 TABLE 18 checkStatus Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION configurationId int N 11 identifier of an existing configuration customerId String Y 30 identifier of specific customer deviceId String Y 30 identifier of specific device serviceId int Y 11 identifier of specific service transactionId string Y 255 indicates a transaction identifier inside the system 100
(325) Table 19 shows an example checkStatus response message for the checkStatus method.
(326) TABLE-US-00021 TABLE 19 checkStatus Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(327) Table 20 shows an example configure request message for the configure method which configures a device by selecting a configuration.
(328) TABLE-US-00022 TABLE 20 configure Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION configurationId int N 11 identifier of an existing configuration customerId String Y 30 identifier of specific customer deviceId String Y 30 identifier of specific device serviceId int Y 11 identifier of specific service transactionId string Y 255 indicates a transaction identifier inside M2M system
(329) Table 21 shows an example configure response message for the checkStatus method.
(330) TABLE-US-00023 TABLE 21 configure Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(331) Table 22 shows an example configureByDetails request message for the configureByDetails method which configures a device by providing configuration parameters.
(332) TABLE-US-00024 TABLE 22 configureByDetails Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION name String Y 50 the name of a parameter configuration value String Y 50 the value of a parameter configuration customerId String Y 30 the identifier of a specific customer deviceId String Y 30 the identifier of a specific device serviceId int Y 11 the identifier of a specific service transactionId String M 255 indicates a transaction identifier inside the system 100
(333) Table 23 shows an example configureByDetails response message for the configureByDetails method.
(334) TABLE-US-00025 TABLE 23 configureByDetails Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(335) Table 24 shows an example deactivate request message for the deactivate method which deactivate a service for a specified device.
(336) TABLE-US-00026 TABLE 24 deactivate Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION configurationId int N 11 identifier of an existing configuration customerId String Y 30 identifier of specific customer deviceId String Y 30 identifier of specific device serviceId int Y 11 identifier of specific service transactionId string Y 255 indicates a transaction identifier inside a system 100
(337) Table 25 shows an example deactivate response message for the deactivate method.
(338) TABLE-US-00027 TABLE 25 deactivate Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(339) Table 26 shows an example insertDevice request message for the insertDevice method which executes the provisioning of a new device.
(340) TABLE-US-00028 TABLE 26 insertDevice Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId String Y 30 identifier of specific customer deviceId String Y 30 identifier of specific device deviceType String Y 255 specifies the device type groupId int Y 11 identifier of the group owning the customer iccid String N 20 the sim iccd ipAddress String N 255 the ip address of the device msisdn String N 15 the phone number associated to the sim transactionId String Y 255 indicates a transaction identifier inside the system 100
(341) Table 27 shows an example insertDevice response message for the insertDevice method.
(342) TABLE-US-00029 TABLE 27 insertDevice Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(343) Table 28 shows an example removeDevice request message for the removeDevice method which removes an existing device.
(344) TABLE-US-00030 TABLE 28 removeDevice Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId String Y 30 The field identifier of specific customer deviceId String Y 30 The field identifier of specific device transactionId String M 255 The field indicates a transaction identifier inside M2M system
(345) Table 29 shows an example removeDevice response message for the removeDevice method.
(346) TABLE-US-00031 TABLE 29 removeDevice Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(347) Table 30 shows an example replaceDevice request message for the replaceDevice method which places a device with the new device. In one implementation, and the new device must be in the provision status.
(348) TABLE-US-00032 TABLE 30 replaceDevice Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId String Y 30 identifier of specific customer old Device String Y 30 identifier of an existing device newDevice String Y 30 identifier of specific new device transactionId String Y 255 indicates a transaction identifier inside the system 100
(349) Table 31 shows an example replaceDevice request message for the replaceDevice method.
(350) TABLE-US-00033 TABLE 31 replaceDevice Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(351) Third party gateway component 218 provides an event handler Web service provides methods to manage the events and alarms that devices send to the platform (e.g., external events) any events generated by the platform (e.g., internal events). In particular, the methods of the event handler Web service: Retrieve alarms and notification of alarms; and Manage rule definitions and execution.
(352)
(353) In one implementation, the exposed methods from the event handler Web service include: activeRule; addAction; addRule; deactiveRule; fineActionsAndParameters; findAlarms; findFields; findFunction; findRules; modifyRuleExpression; modifyRule; removeAction; and removeRule.
(354) Table 32 shows an example activeRule request message for the activeRule method which activates a rule for specified devices.
(355) TABLE-US-00034 TABLE 32 activeRule Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION devices String Y 255 identifies a device ruleName String Y 255 the name of a rule associated with a specific device transactionId String Y 255 indicates a transaction identifier inside the system 100
(356) Table 33 shows an example activeRule response message for the activeRule method.
(357) TABLE-US-00035 TABLE 33 activeRule Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(358) Table 34 shows an example addAction request message for the addAction method which adds an action to a specified rule.
(359) TABLE-US-00036 TABLE 34 addAction Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION actionName String Y 255 The field is the name of an action key String N 255 The field is a parameter key value String N 255 The field is a parameter value ruleName String Y 255 The field is an existing rule name transactionId String Y 255 The field indicates a transaction identifier inside M2M system
(360) Table 35 shows an example addAction response message for the addAction method.
(361) TABLE-US-00037 TABLE 35 addAction Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error)
(362) Table 36 shows an example addRule request message for the addRule method which adds a new rule and associated actions to a specified device.
(363) TABLE-US-00038 TABLE 36 addRule Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION actionName String Y 255 the name of an action customerId String Y 30 identifier of a specific client description String N devices String Y 255 a device expression String Y a logical expression associated to the rule. name String Y 255 the name of the rule key String N 255 a parameter key value String N 255 a parameter value serviceName String Y 255 the name of a service transactionId String Y 255 indicates a transaction identifier inside the system 100
(364) Table 37 shows an example addRule response message for the addRule method.
(365) TABLE-US-00039 TABLE 37 addRule Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error)
(366) Table 38 shows an example deactiveRule request message for the deactiveRule method which deactivates a specified rule for all associated devices.
(367) TABLE-US-00040 TABLE 38 deactiveRule Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION devices String Y 255 The field is a device ruleName String Y 255 The field is the name of a rule associated with one or more device transactionId String Y 255 The field indicates a transaction identifier inside M2M system
(368) Table 39 shows an example deactiveRule response message for the deactiveRule method.
(369) TABLE-US-00041 TABLE 39 deactiveRule Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error)
(370) Table 40 shows an example findActionsAndParameters request message for the findActionsAndParameters method which retrieves all actions and associated parameters available.
(371) TABLE-US-00042 TABLE 40 findActionsAnd Parameters Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION transactionId String Y 255 indicates a transaction identifier inside the system 100
(372) Table 41 shows an example findActionsAndParameters response message for the findActionsAndParameters method.
(373) TABLE-US-00043 TABLE 41 findActionsAnd Parameters Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error) name String N 255 the name of an action param String N 255 a parameter type
(374) Table 42 shows an example findAlarms request message for the findAlarms method which retrieves all alarms by specified parameters.
(375) TABLE-US-00044 TABLE 42 findAlarms Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION baseld int N 11 the identifier of an entity deviceId String N 255 the device identifier from dateTime N the date from to start the search ruleName String N 255 the name of a rule serviceName String N 255 the name of a service statusType String N 45 the Status of an Alarm to dateTime N the date to end the search transactionId String Y 255 indicates a transaction identifier inside the system 100
(376) Table 43 shows an example findAlarms response message for the findAlarms method.
(377) TABLE-US-00045 TABLE 43 findAlarms Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error) baseId int N 11 the identifier of an entity creationDate dateTime N the alarm date creation lastModifyDate dateTime N the last modify date for the alarm ruleName String N 255 the rule name statusType String N 45 the Status of an Alarm
(378) Table 44 shows an example findFields request message for the findFields method which retrieves the list of fields a user can build a rule for a specified service.
(379) TABLE-US-00046 TABLE 44 findFields Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION serviceName String Y 255 the name of a service transactionId String Y 255 indicates a transaction identifier inside M2M system
(380) Table 45 shows an example findFields response message for the findFields method.
(381) TABLE-US-00047 TABLE 45 findFields Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error) fields String N 255 The field is a string with it is possible create a rule
(382) Table 46 shows an example findFunctions request message for the findFunctions method which retrieves the list of functions a user can compose a rule with for a specified service.
(383) TABLE-US-00048 TABLE 46 findFunctions Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION serviceName String Y 255 The field is the name of a service transactionId String Y 255 The field indicates a transaction identifier inside M2M system
(384) Table 47 shows an example findFunctions response message for the findFunctions method.
(385) TABLE-US-00049 TABLE 47 findFunctions Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error) functions String N 255 the function with which user can compose a rule
(386) Table 48 shows an example findRules request message for the findRules method which retrieves rules by customer and service.
(387) TABLE-US-00050 TABLE 48 findRules Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId String N 255 The field is the identifier of a customer deviceId String N 255 The field is the identifier of a device serviceName String N 255 The field is the name of a service transactionId String Y 255 The field indicates a transaction identifier inside M2M system
(388) Table 49 shows an example findRules response message for the findRules method.
(389) TABLE-US-00051 TABLE 49 findRules Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success;1 = error) creationDate dateTime N the creation date of the rule description String N 255 the description of the rule expression String N 65535 the logical expression of the rule lastModifyDate dateTime N the last modify date of the rule name String N 255 the name of the rule
(390) Table 50 shows an example modifyRule request message for the modifyRule method which modifies an expression for a specified rule.
(391) TABLE-US-00052 TABLE 50 modifyRule Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION expression String Y 65535 the logical expression of the rule ruleName String Y 255 the name of the rule transactionId String Y 255 indicates a transaction identifier inside the system 100
(392) Table 51 shows an example modifyRule response message for the modifyRule method.
(393) TABLE-US-00053 TABLE 51 modifyRule Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(394) Table 52 shows an example removeAction request message for the removeAction method which removes an association between an action and a rule.
(395) TABLE-US-00054 TABLE 52 removeAction Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION actionName String Y 255 an action name key String N 255 a parameter key value String N 255 a parameter value ruleName String Y 255 the name of the rule transactionId String N 255 indicates a transaction identifier inside the system 100
(396) Table 53 shows an example removeAction response message for the removeAction method.
(397) TABLE-US-00055 TABLE 53 removeAction Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(398) Table 54 shows an example removeRule request message for the removeRule method which removes a specified rule and associated entities.
(399) TABLE-US-00056 Table 54 removeRule Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION transactionId String Y 255 the identifier of an existing transaction
(400) Table 55 shows an example removeRule response message for the removeRule method.
(401) TABLE-US-00057 TABLE 55 removeRule Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(402)
(403) The system configuration Web service provides methods to manage relationships between customers, services, groups and projects. In particular the methods of the system configuration Web service: Associate/Disassociate groups and projects; and Activate/Deactivate services for customers. The exposed methods from the system configuration Web service include: associateGroupToProject; customerDomainSubscription; customerDomainUnsubscription; and deassociateGroupFromProject.
(404) Table 56 shows an example groupProject request message for the groupProject method which associates a group and a project specified in the request.
(405) TABLE-US-00058 TABLE 56 groupProject Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION groupId int Y 10 the identifier of a specific group projectId int Y 10 the identifier of a specific project transactionId String Y 255 indicates a transaction identifier inside M2M system
(406) Table 57 shows an example groupProject response message for the groupProject method.
(407) TABLE-US-00059 TABLE 57 groupProject Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(408) Table 58 shows an example customerDomainSubscription request message for the customerDomainSubscription method which activates a service for the customer specified in the request.
(409) TABLE-US-00060 TABLE 58 customerDomainSubscription Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId string Y 30 the identifier of a specific custumer serviceId int Y 10 the identifier of a specific service transaction Id String Y 255 indicates a transaction identifier inside the system 100
(410) Table 59 shows an example customerDomainSubscription response message for the customerDomainSubscription method.
(411) TABLE-US-00061 TABLE 59 customerDomainSubscription Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(412) Table 60 shows an example customerDomainUnsubscription request message for the customerDomainUnsubscription method which deactivates a service for a specified customer in the request.
(413) TABLE-US-00062 TABLE 60 customerDomainUnsubscription Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION customerId string Y 30 The field is the identifier of a specific custumer serviceId int Y 10 The field is the identifier of a specific service transaction Id String Y 255 The field indicates a transaction identifier inside M2M system
(414) Table 61 shows an example customerDomainUnsubscription response message for the customerDomainUnsubscription method.
(415) TABLE-US-00063 TABLE 61 customerDomainUnsubscription Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(416) Table 62 shows an example deassociateGroupFromProject request message for the deassociateGroupFromProject method which disassociate a group and a project specified in the request.
(417) TABLE-US-00064 TABLE 62 deassociateGroupFromProject Request Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION groupId int Y 10 the identifier of a specific group projectId int Y 10 the identifier of a specific project transaction Id String Y 255 indicates a transaction identifier inside the system 100
(418) Table 63 shows an example deassociateGroupFromProject response message for the deassociateGroupFromProject method.
(419) TABLE-US-00065 TABLE 63 deassociateGroupFrom Project Response Message DATA ELEMENT TYPE MANDATORY SIZE DESCRIPTION errorCode int Y 11 contains the code returned by the request. this code may indicate either error or success. errorDesc String Y 255 Contains the description if the error code. statusCode int Y 11 Describes the status associated to the error code (0 = success; 1 = error)
(420) Table 64 shows an example list of response codes that may be returned in the send responses from each web service.
(421) TABLE-US-00066 TABLE 64 response codes Code Type Text Description 1000 Error request successful done Successfully executed code 1001 Error events was not found by An error was occurred or code device id: nothing was found by the request 1002 Error commands was not found by An error was occurred or code device id: . . . nothing was found by the Fields was not found for request service: . . . Functions was not found service: Customer with id “ . . . ” was not found Service with name “ . . . ” was not found Rules was not found “Device with id “ . . . ” was not found” Rule with name “ . . . ” was not found Alarms was not found Action with name “ . . . ” was not found 0 Status — Success (associated to the Code errorCode 1000) 1 Status — Error ( associated with Code any erroCode that indicates error 1001-1002 etc.) 1008 Error check status request already An error was occurred or Code opened, wait for request's nothing was found by the expire request 2001 Error IB generic error Code 2101 Error IB- Data Access generic Code error 2102 Error Error generated by an Code invocation to CSM 2103 Error event not found by id: . . . Bad input parameters Code commands was not found by device id: . . . No Group with specified ID found No project with specified ID found No customer with specified ID found No service with specified ID found Some Device associated to Service with status ACTIVE or ACTIVATION_IN_PROGRESS exists for specified Customer 2104 Error Error generated by an Code invocation to DCM 2105 Error IB-Data Access generic Code error 2106 Error Code 2107 Error a file specified in Code Repository table can not be found 2108 Error Error generated by an Code invocation to EH 2109 Error events was not found by IB element not found Code device id: . . . 4001 Error Event Handler generic Code error 4002 Error Event Handler Bad Input Code parameter 4003 Error Event Handler no value Code found 3001 Error DCM generic error Code 3002 Error DCM bad input parameter Code
(422) Table 65 shows an example listing of a DataAccess.wsdl.
(423) TABLE-US-00067 TABLE 65 DataAccess.wsdl <?xml version=″1.0″ encoding=″UTF-8″?> <definitions name=″DataAccessInterface″ targetNamespace=″http://services.infobroker.m2m.amos.company.com″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:ns1=″infobroker.m2m.amos.company.com/eventType″ xmlns:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:ns2=″infobroker.m2m.amos.company.com/eventId″ xmlns:soap=″http://schemas.xmlsoap.org/wsdl/soap/″ xmlns=″http://schemas.xmlsoap.org/wsdl/″> <types> <xs:schema targetNamespace=″infobroker.m2m.amos.company.com/eventType″ version=″1.0″ xmlns:ns1=″http://services.infobroker.m2m.amos.company.com″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs: import namespace=″http://services.infobroker.m2m.amos.company.com″/> <xs:element name=″event Type″ type=″ns1:eventType″/> </xs:schema> <xs:schema targetNamespace=″infobroker.m2m.amos.company.com/eventId″ version=″1.0″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs:element name=″eventId″ type=″xs:int″/> </xs:schema> <xs:schema targetNamespace=″http://services.infobroker.m2m.amos.company.com″ version=″1.0″ xmlns:ns1=″infobroker.m2m.amos.company.com/eventType″ xmlns:ns2=″infobroker.m2m.amos.company.com/eventId″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs:import namespace=″infobroker.m2m.amos.company.com/eventType″/> <xs:import namespace=″infobroker.m2m.amos.company.com/eventId″/> <xs:complexType name=″subscribeRequest″> <xs:sequence> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element name=″eventId″ type=″xs:int″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″dataAccessResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″errorCode″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″errorDesc″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusCode″ type=″xs:int″/> </xs:sequence> </xs:complexType> <xs:complexType name=″commandRequest″> <xs:sequence> <xs:element minOccurs=″0″ name=″commandType″ type=″tns:commandTypes″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″fromDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″status″ type=″tns:statusType″/> <xs:element minOccurs=″0″ name=″toDate″ type=″xs:dateTime″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″commandResponse″> <xs:complexContent> <xs:extension base=″tns:dataAccessResponse> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″commands″ nillable=″true″ type=″tns:command″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″command″> <xs:sequence> <xs:element minOccurs=″0″ name=″commandId″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″commandType″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″lastDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″status″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″eventRequest″> <xs:sequence> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element minOccurs=″0″ ref=″ns1:eventType″/> <xs:element minOccurs=″0″ name=″fromDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″toDate″ type=″xs:dateTime″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″eventResponse″> <xs:complexContent> <xs:extension base=″tns:dataAccessResponse″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″events″ nillable=″true″ type=″tns:event″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″event″> <xs:sequence> <xs:element minOccurs=″0″ name=″eventId″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″eventType″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″lastDate″ type=″xs:dateTime″/> </xs:sequence> </xs:complexType> <xs:complexType name=″eventDetailRequest″> <xs:sequence> <xs:element minOccurs=″0″ ref=″ns2:eventId″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″eventDetailResponse″> <xs:complexContent> <xs:extension base=″tns:dataAccessResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″arrayOfDetail″ type=″tns: arrayOfDetail″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″arrayOfDetail″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″details″ nillable=″true″ type=″tns:detail″/> </xs:sequence> </xs:complexType> <xs:complexType name=″detail″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″attributes″ nillable=″true″ type=″tns:attribute″/> <xs:element minOccurs=″0″ name=″name″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″attribute″> <xs:sequence> <xs:element minOccurs=″0″ name=″name″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″value″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:simpleType name=″commandTypes″> <xs:restriction base=″xs:string″> <xs:enumeration value=″PUT_DEVICE″/> <xs:enumeration value=″REMOVE_DEVICE″/> <xs:enumeration value=″REPLACE_DEVICE″/> <xs:enumeration value=″ACTIVATE_SERVICE″/> <xs:enumeration value=″DEACTIVATE_SERVICE″/> <xs:enumeration value=″SUBSCRIBE_EVENT″/> <xs:enumeration value=″UNSUBSCRIBE_EVENT″/> <xs:enumeration value=″CONFIGURE_DEVICE″/> <xs:enumeration value=″CHECK_STATUS″/> </xs:restriction> </xs:simpleType> <xs:simpleType name=″statusType″> <xs:restriction base=″xs:string″> <xs:enumeration value=″PROVISIONING″/> <xs:enumeration value=″PROVISIONED″/> <xs:enumeration value=″INSTALLED″/> <xs:enumeration value=″UNINSTALLED″/> <xs:enumeration value=″ACTIVATING″/> <xs:enumeration value=″ACTIVATED″/> <xs:enumeration value=″ACTIVATION_IN_PROGRESS″/> <xs:enumeration value=″ACTIVE″/> <xs:enumeration value=″DEACTIVATING″/> <xs:enumeration value=″DEACTIVATED″/> <xs:enumeration value=″DEACTIVE″/> <xs:enumeration value=″REPLACING″/> <xs:enumeration value=″REPLACED″/> <xs:enumeration value=″DELETING″/> <xs:enumeration value=″DELETED″/> <xs:enumeration value=″SUBSCRIBED″/> <xs:enumeration value=″UNSUBSCRIBED″/> <xs:enumeration value=″ERROR″/> <xs:enumeration value=″CONFIGURING″/> <xs:enumeration value=″CONFIGURED″/> <xs:enumeration value=″CHECK_IN_PROGRESS″/> <xs:enumeration value=″CHECKED″/> <xs:enumeration value=″CHECK_FAILED″/> </xs:restriction> </xs:simpleType> <xs:simpleType name=″eventType″> <xs:restriction base=″xs:string″> <xs:enumeration value=″SAMPLING″/> <xs:enumeration value=″LOGGING″/> </xs:restriction> </xs:simpleType> </xs:schema> </types> <message name=″DataAccess_unsubscribe″> <part name=″request″ type=″tns:subscribeRequest″/> </part> </message> <message name=″DataAccess_findEventDetailsByDeviceId″> <part name=″request″ type=″tns:eventRequest″> </part> </message> <message name=″DataAccess_findEventDetail″> <part name=″request″ type=tns:eventDetailRequest″> </part> </message> <message name=″DataAccess_findEventByDeviceId″> <part name=″request″ type=tns:eventRequest″> </part> </message> <message name=″DataAccess_findCommandByDeviceId″> <part name=″request″ type=tns:commandRequest″> </part> </message> <message name=″DataAccess_findCommandByDeviceIdResponse″> <part name=″response″ type=″tns:commandResponse″> </part> </message> <message name=″DataAccess_subscribe″> <part name=″request″ type=″tns:subscribeRequest″> </part> </message> <message name=″DataAccess_findEventByDeviceIdResponse″> <part name=″response″ type=″tns:eventResponse″> </part> </message> <message name=″DataAccess_subscribeResponse″> <part name=″response″ type=″tns:dataAccessResponse″> </part> </message> <message name=″DataAccess_findEventDetailsByDeviceIdResponse″> <part name=″response″ type=″tns:eventDetailResponse″> </part> </message> <message name=″DataAccess_findEventDetailResponse″> <part name=″response″ type=″tns:eventDetailResponse″> </part> </message> <message name=″DataAccess_unsubscribeResponse″> <part name=″response″ type=″tns:dataAccessResponse″> </part> </message> <portType name=″DataAccess″> <operation name=″findCommandByDeviceId″ parameterOrder=″request″> <input message=″tns:DataAccess_findCommandByDeviceId″> </input> <output message=″tns:DataAccess_findCommandByDeviceIdResponse″> </output> </operation> <operation name=″findEventByDeviceId″ parameterOrder=″request″> <input message=″tns:DataAccess_findEventByDeviceId″> </input> <output message=″tns:DataAccess_findEventByDeviceIdResponse″> </output> </operation> <operation name=″findEventDetail″ parameterOrder=″request″> <input message=″tns:DataAccess_findEventDetail″> </input> <output message=″tns:DataAccess_findEventDetailResponse″> </output> </operation> <operation name=″findEventDetailsByDeviceId″ parameterOrder=″request″> <input message=″tns:DataAccess_findEventDetailsByDeviceId″> </input> <output message=″tns:DataAccess_findEventDetailsByDeviceIdResponse″> </output> </operation> <operation name=″subscribe″ parameterOrder=″request″> <input message=″tns:DataAccess_subscribe″> </input> <output message=″tns:DataAccess_subscribeResponse″> </output> </operation> <operation name=″unsubscribe″ parameterOrder=″request″> <input message=″tns:DataAccess_unsubscribe″> </input> <output message=″tns:DataAccess_unsubscribeResponse″> </output> </operation> </portType> <binding name=″DataAccessBinding″ type=″tns:DataAccess″> <soap:binding style=″rpc″ transport=″http://schemas.xmlsoap.org/soap/http″/> <operation name=″findCommandByDeviceId″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″findEventByDeviceId″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″findEventDetail″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″findEventDetailsByDeviceId″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″subscribe″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″unsubscribe″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> </binding> <service name=″DataAccessInterface″> <port name=″DataAccessPort″ binding=″tns:DataAccessBinding″> <soap:address location=″http://192.168.83.208:18080/M2M/InfoBrokerDataAccess″/> </port> </service> </definitions>
(424) Table 66 shows an example listing of a DeviceManager.wsdl.
(425) TABLE-US-00068 TABLE 66 DeviceManager.wsdl <?xml version=″1.0″encoding=″UTF-8″?> <definitions name=″DeviceManagerInterface″ targetNamespace=″http://services.infobroker.m2m.amos.company.com″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:soap= ″http://schemas.xmlsoap.org/wsdl/soap/″ xmlns=″http://schemas.xmlsoap.org/wsdl/″> <types> <xs:schema targetNamespace=″http://services.infobroker.m2m.amos.company.com″ version=″1.0″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs:complexType name=″deviceManagerRequest″> <xs:sequence> <xs:element minOccurs=″0″ name=″configurationId″ type=″xs:int″/> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element name=″serviceId″ type=″xs:int″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″deviceManagerResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″errorCode″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″errorDesc″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusCode type=″xs:int″/> </xs:sequence> </xs:complexType> <xs:complexType name=″removeDeviceRequest″> <xs:sequence> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″replaceDeviceRequest″> <xs:sequence> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″oldDevice″ type=″xs:string″/> <xs:element name=″newDevice″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″insertDeviceRequest″> <xs:sequence> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element name=″device Type″ type=″xs:string″/> <xs:element name=″groupId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″iccid″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″ipAddress″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″msisdn″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″deviceManagerConfigurationRequest″> <xs:sequence> <xs:element name=″arrayOfDetail″ type=″tns:arrayOfDetail″/> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″deviceId″ type=″xs:string″/> <xs:element name=″serviceId″ type=″xs:int″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″arrayOfDetail″> <xs:sequence> <xs:element maxOccurs=″unbounded″ name=″details″ type=″tns:detail″/> </xs:sequence> </xs:complexType> <xs:complexType name=″detail″/> <xs:sequence> <xs:element maxOccurs=″unbounded″ name=″attributes″ type=″tns:attribute″/> </xs:sequence> </xs:complexType> <xs:complexType name=″attribute″> <xs:sequence> <xs:element name=″name″ type=″xs:string″/> <xs:element name=″value″ type=″xs:string″/> </xs:sequence> </xs:complexType> </xs:schema> </types> <message name=″DeviceManager_replaceDeviceResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_checkStatusResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_deactivate″> <part name=″request″ type=″tns:deviceManagerRequest″> </part> </message> <message name=″DeviceManager_activate″> <part name=″request″ type=″tns:deviceManagerRequest″/> </part> </message> <message name=″DeviceManager_configure″> <part name=″request″ type=″tns:deviceManagerRequest″> </part> </message> <message name=″DeviceManager_removeDeviceResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_configureResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_deactivateResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_insertDevice″> <part name=″request″ type=″tns:insertDeviceRequest″> </part> </message> <message name=″DeviceManager_insertDeviceResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_replaceDevice″> <part name=″request″ type=″tns:replaceDeviceRequest″/> </part> </message> <message name=″DeviceManager_configureByDetailsResponse″> <part name=″response″ type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_removeDevice″> <part name=″request″ type=″tns:removeDeviceRequest″> </part> </message> <message name=″DeviceManager_configureByDetails″> <part name=″request″ type=″tns:deviceManagerConfigurationRequest″> </part> </message> <message name=″DeviceManager_activateResponse″> <part name=″response″type=″tns:deviceManagerResponse″> </part> </message> <message name=″DeviceManager_checkStatus″> <part name=″request″ type=″tns:deviceManagerRequest″> </part> </message> <portType name=″DeviceManager″> <operation name=″activate″ parameterOrder=″request″> <input message=″tns:DeviceManager_activate″> </input> <output message=″tns:DeviceManager_activateResponse″> </output> </operation> <operation name=″checkStatus″ parameterOrder=″request″> <input message=″tns:DeviceManager_checkStatus″> </input> <output message=″tns:DeviceManager_checkStatusResponse″> </output> </operation> <operation name=″configure″ parameterOrder=″request″> <input message=″tns:DeviceManager_configure″> </input> <output message=″tns:DeviceManager_configureResponse″> </output> </operation> <operation name=″configureByDetails″ parameterOrder=″request″> <input message=″tns:DeviceManager_configureByDetails″> </input> <output message=″tns:DeviceManager_configureByDetailsResponse″> </output> </operation> <operation name=″deactivate″ parameterOrder=″request″> <input message=″tns:DeviceManager_deactivate″> </input> <output message=″tns:DeviceManager_deactivateResponse″> </output> </operation> <operation name=″insertDevice″ parameterOrder=″request″> <input message=″tns:DeviceManager_insertDevice″> </input> <output message=″tns:DeviceManager_insertDeviceResponse″> </output> </operation> <operation name=″removeDevice″ parameterOrder=″request″> <input message=″tns:DeviceManager_removeDevice″> </input> <output message=″tns:DeviceManager_removeDeviceResponse″> </output> </operation> <operation name=″replaceDevice″ parameterOrder=″request″> <input message=″tns:DeviceManager_replaceDevice″> </input> <output message=″tns:DeviceManager_replaceDeviceResponse″> </output> </operation> </portType> <binding name=″DeviceManagerBinding″ type=″tns:DeviceManager″> <soap:binding style=″rpc″ transport=″http://schemas.xmlsoap.org/soap/http″/> <operation name=″activate″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://servicesinfobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″checkStatus″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″configure″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″configureByDetails″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″deactivate″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″insertDevice″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″removeDevice″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> <operation name=″replaceDevice″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company. com″/> </output> </operation> </binding> <service name=″DeviceManagerInterface″> <port name=″DeviceManagerPort″ binding=″tns:DeviceManagerBinding″> <soap:address location=″http://127.0.0.1:8080/M2M/InfoBrokerDeviceManager″/> </port> </service> </definitions>
(426) Table 67 shows an example listing of an EventHandler.wsdl.
(427) TABLE-US-00069 TABLE 67 EventHandler.wsdl <?xml version=″1.0″ encoding=″UTF-8″?> <definitions name=″EventHandlerInterface″ targetNamespace=″http://services.infobroker.m2m.amos.company.com″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:soap=″http://schemas.xmlsoap.org/wsdl/soap/″ xmlns=″http://schemas.xmlsoap.org/wsdl/″> <types> <xs:schema targetNamespace=″http://services.infobroker.m2m.amos.company.com″ version=″1.0″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs:complexType name=″addRuleReguest″> <xs:sequence> <xs:element minOccurs=″0″ name=″actionName″ type=″xs:string″/> <xs:element name=″customerId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″description″ type=″xs:string″/> <xs:element maxOccurs=″unbounded″ name=″devices″ type=″xs:string″/> <xs:element name=″expression″ type=″xs:string″/> <xs:element name=″name″ type=″xs:string″/> <xs:element name=″parameters″> <xs:complexType> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″entry″> <xs:complexType> <xs:sequence> <xs:element minOccurs=″0″ name=″key″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″value″ type=″xs:string″/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=″serviceName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″eventHandlerResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″errorCode″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″errorDesc″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusCode″ type=″xs:int″/> </xs:sequence> </xs:complexType> <xs:complexType name=″addActionRequest″> <xs:sequence> <xs:element name=″actionName″ type=″xs:string″/> <xs:element name=″parameters″> <xs:complexType> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″entry″> <xs:complexType> <xs:sequence> <xs:element minOccurs=″0″ name=″key″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″value″ type=″xs:string″/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=″ruleName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″fieldRequest″> <xs:sequence> <xs:element name=″serviceName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″fieldResponse″> <xs:complexContent> <xs:extension base=″tns:eventHandlerResponse″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″fields″ nillable=″true″ type=″xs:string″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″functionRequest″> <xs:sequence> <xs:element name=″serviceName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″functionResponse″> <xs:complexContent> <xs:extension base=″tns:eventHandlerResponse″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″functions″ nillable=″true″ type=″xs:string″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″eventHandlerRequest″> <xs:sequence> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″actionResponse″> <xs:complexContent> <xs:extension base=″tbs:eventHandlerResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″actionParams″ type=″tns:listKeyListType″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=″listKeyListType″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″action″ type=″tns:keyListType″/> </xs:sequence> </xs:complexType> <xs:complexType name=″keyListType″> <xs:sequence> <xs:element minOccurs=″0″ name=″name″ type=″xs:string″/> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″param″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″findRuleRequest″> <xs:sequence> <xs:element minOccurs=″0″ name=″customerId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″deviceId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″serviceName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″findRuleResponse″> <xs:complexContent> <xs:extension base=″tns:eventHandlerResponse″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″rules″ nillable=″true″ type=″tns:rule″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name= ″rule″> <xs:sequence> <xs:element minOccurs=″0″ name=″creationDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″description″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″expression″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″lastModifyDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″name″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″alarmRequest″> <xs:sequence> <xs:element minOccurs=″0″ name=″baseId″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″deviceId″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″from″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″ruleName″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″serviceName″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusType″ type=″tns:statusType″/> <xs:element minOccurs=″0″ name=″to″ type=″xs:dateTime″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″alarmResponse″> <xs:complexContent> <xs:extension base=″tns:eventHandlerResponse″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″alarms″ nillable=″true″ type=″tns:alarm″/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name= ″alarm″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″alarmhistories″ nillable=″true″ type=″tns:alarmhistory″/> <xs:element name=″baseId″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″creationDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″lastModifyDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″ruleName″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusType″ type=″tns:statusType″/> </xs:sequence> </xs:complexType> <xs:complexType name=″alarmhistory″> <xs:sequence> <xs:element minOccurs=″0″ name=″creationDate″ type=″xs:dateTime″/> <xs:element minOccurs=″0″ name=″statusType″ type=″tns:statusType″/> </xs:sequence> </xs:complexType> <xs:complexType name=″removeRuleRequest″> <xs:sequence> <xs:element name=″name″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″activeDeactiveRuleRequest″> <xs:sequence> <xs:element maxOccurs=″unbounded″ minOccurs=″0″ name=″devices″ nillable=″true″ type=″xs:string″/> <xs:element name=″ruleName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″modifyRuleRequest″> <xs:sequence> <xs:element name=″expressian″ type=″xs:string″/> <xs:element name=″ruleName″ type=″xs:string″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:simpleType name=″statusType″> <xs:restriction base=″xs:string″> <xs:enumeration value=″ACTIVE″/> <xs:enumeration value=″DEACTIVE″/> <xs:enumeration value=″CREATED″/> <xs:enumeration value=″LOADED″/> <xs:enumeration value=″EXECUTED″/> <xs:enumeration value=″ERROR″/> <xs:enumeration value=″CLOSED″/> </xs:restriction> </xs:simpleType> </xs:schema> </types> <message name=″EventHandler_modifyRuleExpressionResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_removeRuleResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_removeRule″> <part name=″request″ type=″tns:removeRuleRequest″> </part> </message> <message name=″EventHandler_modifyRuleExpression″> <part name=″request″ type=″tns:modifyRuleRequest″> </part> </message> <message name=″EventHandler_removeAction″> <part name=″request″ type=″tns:addActionRequest″> </part> </message> <message name=″EventHandler_findFunctions″ <part name=″request″ type=″tns:functionRequest″> </part> </message> <message name=″EventHandler_removeActionResponse″> <part name= ″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_findFieldsResponse″> <part name= ″response″ type=″tns:fieldResponse″> </part> </message> <message name=″EventHandler_addAction″> <part name=″request″ type=″tns:addActionRequest″> </part> </message> <message name=″EventHandler_addActionResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_findActionsAndParamiters″> <part name=″request″ type=″tns:eventHandlerRequest″ </part> </message> <message name=″EventHandler_findActionsAndParamitersResponse″> <part name= ″response″ type=″tns:actionResponse″> </part> </message> <message name=″EventHandler_findFields″> <part name=″request″ type=″tns:fieldRequest″> </part> </message> <message name=″EventHandler_activeRule″> <part name=″request″ type=″tns:activeDeactiveRuleRequest″> </part> </message> <message name=″EventHandler_findAlarms″> <part name=″request″ type=″tns:alarmRequest″> </part> </message> <message name=″EventHandler_findAlarmsResponse″> <part name=″response″ type=″tns:alarmResponse″> </part> </message> <message name=″EventHandler_findRules″> <part name=″request″ type=″tns:findRuleRequest″> </part> </message> <message name=″EventHandler_findFunctionsResponse″> <part name=″response″ type=″tns:functionResponse″> </part> </message> <message name=″EventHandler_addRuleResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_activeRuleResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <message name=″EventHandler_addRule″> <part name=″request″ type=″tns:addRuleRequest″> </part> </message> <message name=″EventHandler_deactiveRule″> <part name=″request″ type=″tns:activeDeactiveRuleRequest″> </part> </message> <message name=″EventHandler_findRulesResponse″> <part name=″response″ type=″tns:findRuleResponse″> </part> </message> <message name=″EventHandler_deactiveRuleResponse″> <part name=″response″ type=″tns:eventHandlerResponse″> </part> </message> <portType name=″EventHandler″> <operation name=″activeRule″ parameterOrder=″request″> <input message=″tns:EventHandler_activeRule″> </input> <output message=″tns:EventHandler_activeRuleResponse″> </output> </operation> <operation name=″addAction″ parameterOrder=″request″> <input message=″tns:EventHandler_addAction″> </input> <output message=″tns:EventHandler_addActionResponse″> </output> </operation> <operation name=″addRule″ parameterOrder=″request″> <input message=″tns:EventHandler_addRule″> </input> <output message=″tns:EventHandler_addRuleResponse″> </output> </operation> <operation name=″deactiveRule″ parameterOrder=″request″> <input message=″tns:EventHandler_deactiveRule″> </input> <output message=″tns:EventHandler_deactiveRuleResponse″> </output> </operation> <operation name=″findActionsAndParamiters″ parameterOrder=″request″> <input message=″tns:EventHandler_findActionsAndParamiters″> </input> <output message=″tns:EventHandler_findActionsAndParamitersResponse″> </output> </operation> <operation name=″findAlarms″ parameterOrder=″request″> <input message=″tns:EventHandler_findAlarms″> </input> <output message=″tns:EventHandler_findAlarmsResponse″> </output> </operation> <operation name=″findFields″ parameterOrder=″request″> <input message=″tns:EventHandler_findFields″> </input> <output message=″tns:EventHandler_findFieldsResponse″> </output> </operation> <operation name=″findFunctions″ parameterOrder=″request″> <input message=″tns:EventHandler_findFunctions″> </input> <output message=″tns:EventHandler_findFunctionsResponse″> </output> </operation> <operation name=″findRules″ parameterOrder=″request″> <input message=″tns:EventHandler_findRules″> </input> <output message=″tns:EventHandler_findRulesResponse″> </output> </operation> <operation name=″modifyRuleExpression″ parameterOrder=″request″> <input message=″tns:EventHandler_modifyRuleExpression″> </input> <output message=″tns:EventHandler_modifyRuleExpressionResponse″> </output> </operation> <operation name=″removeAction″ parameterOrder=″request″> <input message=″tns:EventHandler_removeAction″> </input> <output message=″tns:EventHandler_removeActionResponse″> </output> </operation> <operation name=″removeRule″ parameterOrder=″request″> <input message=″tns:EventHandler_removeRule″> </input> <output message=″tns:EventHandler_removeRuleResponse″> </output> </operation> </portType> <binding name=″EventHandlerBinding″ type=″tns:EventHandler″> <soap:binding style=″rpc″ transport=″http://schemas.xmlsoap.org/soap/http″/> <operation name=″activeRule″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″addAction″″> <soap:operation soapAction=″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″addRule″ <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″deactiveRule″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″findActionsAndParamiters″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″findAlarms″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″findFields″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″findFunctions″ <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″findRules″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″modifyRuleExpression″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″removeAction″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″removeRule″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> </binding> <service name=″EventHandlerInterface″> <port name=″EventHandlerPort″ binding=″tns:EventHandlerBinding″> <soap:address location=″http://127.0.0.1:8080/M2M/InfoBrokerEventHandler″/> </port> </service> </definitions>
(428) Table 68 shows an example listing of a SystemConfiguration.wsdl.
(429) TABLE-US-00070 TABLE 68 SystemConfiguration.wsdl <?xml version=″1.0″ encoding=″UTF-8″?> <definitions name=″SystemConfigurationInterface″ targetNamespace=″http://services.infobroker.m2m.amos.company.com″ xmlns:tns=″http://services.infobroker.m2m.amos.company.com″ xmlns:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:soap=″http://schemas.xmlsoap.org/wsdl/soap/″ xmlns=″http://schemas.xmlsoap.org/wsdl/″> <types> <xs:schema targetNamespace=″http://services.infobroker.m2m.amos.company.com″ version=″1.0″ xmlns:xs=″http://www.w3.org/2001/XMLSchema″> <xs:complexType name=″customerServiceRequest″> <xs:seguence> <xs:element name=″customerId″ type=″xs:string″/> <xs:element name=″serviceId″ type=″xs:int″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> <xs:complexType name=″systemConfigurationResponse″> <xs:sequence> <xs:element minOccurs=″0″ name=″errorCode″ type=″xs:int″/> <xs:element minOccurs=″0″ name=″errorDesc″ type=″xs:string″/> <xs:element minOccurs=″0″ name=″statusCode″ type=″xs:int″/> </xs:sequence> </xs:complexType> <xs:complexType name=″groupProjectRequest″> <xs:sequence> <xs:element name=″groupId″ type=″xs:int″/> <xs:element name=″projectId″ type=″xs:int″/> <xs:element name=″transactionId″ type=″xs:string″/> </xs:sequence> </xs:complexType> </xs:schema> </types> <message name=″SystemConfiguration_deassociateGroupFromProjectResponse″> <part name=″response″ type=″tns:systemConfigurationResponse″> </part> </message> <message name=″SystemConfiguration_customerDomainSubscription″> <part name=″request″ type=″tns:customerServiceRequest″> </part> </message> <message name=″SystemConfiguration_deassociateGroupFromProject″> <part name=″request″ type=″tns:groupProjectRequest″> </part> </message> <message name=″SystemConfiguration_customerDomainUnsubscriptionResponse″> <part name=″response″ type=″tns:systemConfigurationResponse″> </part> </message> <message name=″SystemConfiguration_customerDomainUnsubscription″> <part name=″request″ type=″tns:customerServiceRequest″> </part> </message> <message name=″SystemConfiguration_customerDomainSubscriptionResponse″> <part name=″response″ type=″tns:systemConfigurationResponse″> </part> </message> <message name=″SystemConfiguration_associateGroupToProject″> <part name=″request″ type=″tns:groupProjectRequest″> </part> </message> <message name=″SystemConfiguration_associateGroupToProjectResponse″> <part name=″response″ type=″tns:systemConfigurationResponse″> </part> </message> <portType name=″SystemConfiguration″> <operation name=″associateGroupToProject″ parameterOrder=″request″> <input message=″tns:SystemConfiguration_associateGroupToProject″> </input> <output message=″tns:SystemConfiguration_associateGroupToProjectResponse″> </output> </operation> <operation name=″customerDomainSubscription″ parameterOrder=″request″> <input message=″ths:SystemConfiguration_customerDomainSubscription″> </input> <output message=″ths:SystemConfiguration_customerDomainSubscriptionResponse″> </output> </operation> <operation name=″customerDomainUnsubscription″ parameterOrder=″request″> <input message=″tns:SystemConfiguration_customerDomainUnsubscription″> </input> <output message=″tns:SystemConfiguration_customerDomainUnsubscriptionResponse″> </output> </operation> <operation name=″deassociateGroupFromProject″ parameterOrder=″request″> <input message=″tns:SystemConfiguration_deassociateGroupFromProject″> </input> <output message=″tns:SystemConfiguration_deassociateGroupFromProjectResponse″> </output> </operation> </portType> <binding name=″SystemConfigurationBinding″ type=″tns:SystemConfiguration″> <soap:binding style=″rpc″ transport=″http://schemas.xmlsoap.org/soap/http″/> <operation name=″associateGroupToProject″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use= ″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″customerDomainSubscription″> <soap:operation soapAction=″″/> <input> <soap:body use= ″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use= ″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″customerDomainUnsubscription″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> <operation name=″deassociateGroupFromProject″> <soap:operation soapAction=″″/> <input> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </input> <output> <soap:body use=″literal″ namespace=″http://services.infobroker.m2m.amos.company.com″/> </output> </operation> </binding> <service name=″SystemConfigurationInterface″> <port name=″SystemConfigurationPort″ binding=″tns:SystemConfigurationBinding″> <soap:address location=″http://127.0.0.1:8080/M2M/InfoBrokerSystemConfiguration″/> </port> </service> </definitions>
(430) Some characteristics of exemplary services which may be supported by the Platform 102 are given below:
(431) Service: Home Control & Smart Metering
(432) 1. End User joins a Residential Building offering through a Vertical Portal and pays for the subscription using a Mobile Money management offering.
(433) 2. Third party service provider or user configures and upgrade/downgrade Home controller capabilities.
(434) 3. End user downloads a controller application on his mobile phone that implements a soft panel integrating information (metering, status), control (turn on/off), or other functions.
(435) The end user with the own mobile phone will be able to: keep power costs under control; optimize energy savings, for example, lamp dimmer regulation in order to keep constant the light in a room depending on the presence or absence of persons; keep environmental values (temperature, light, air quality) under defined thresholds and receive alarms; monitor real time status for each appliance, receive warnings for abnormal values; detect and respond to human presence in a room, and other capabilities.
(436) Service: Enterprise Building Control & Security
(437) 1. Enterprise joins a Building Control & Security offering through Vertical Portal and pays for the subscription using Mobile Money management offering
(438) 2. Service Provider is able to configure and upgrade/downgrade Building controller capabilities.
(439) 3. Enterprise building will be cabled in order to register:
(440) Employee access, thought a badge/face recognition/NFC or RFID stick.
(441) Energy consumption, compared with thresholds in order to reduce wastes and managing alarms.
(442) Environmental values (temperature, light, air quality) top keep them under defined thresholds.
(443) Schedules for turning on/off of lights group, heating plant.
(444) Optimize energy savings.
(445) Enterprise Administration manages and monitors all the control and security equipment using, for example, a mobile phone.
(446) Service: Remote HealthCare
(447) 1. End User/Doctor interacts with or provides hospital treatment at patient's home through Digital Pen technology or via Health Care Vertical Portal.
(448) 2. End User/Patient is able to measure the following device values which are reported to the architecture 100:
(449) Glucometer
(450) Blood Pressure
(451) Weight
(452) Hearth beat, or other health data
(453) 3. End User/Patient sends data to Hospital Data Center.
(454) 4. End User/Doctor sends to patient the correct therapy based on last measurement.
(455) Service: Pharmacy Automation
(456) 1. Based on diagnostic report within Health Care scenario or during medical check-up, a doctor prepares a medical prescription through a mobile device application.
(457) 2. Medical prescription is sent to patient via medical virtual voucher creating a “patient barcode”.
(458) 3. Patient requests medicine at pharmacy through medical virtual voucher assigned by the doctor.
(459) 4. Patient pays for medicine using contactless mobile point of sale device.
(460) Service: Wellness Empowerment
(461) 1. Gym creates a technology environment and service automate the End User approach to the equipment.
(462) 2. End User subscribes to the service through a Retailer Mobile Portal and receives an SMS for mobile application download.
(463) 3. User will pay in “pay as you use” or subscription mode. Payments are managed through a Mobile Money Management service
(464) 4. For subscription mode, the End User receives the service pass enabled with a barcode through his mobile application.
(465) 5. End User access the services (e.g., gym equipment) through his personal pass: smart gym equipment recognizes the End User, traces training performances and suggests how to improve the training.
(466) 6. Personal trainer can access the record for the End User in order to correctly tune the training.
(467) 7. End User is able to accesses the training chart and training performance through a kiosk within the gym.
(468) 8. Through the healthcare equipment, weight, hearthbeat, and blood pressure are monitored; in case critical values are reached due to training, both the doctor and the personal trainer are alerted through SMS; both the medical record and the training chart are updated.
(469) 9. Gym Admin is able to attribute loyalty points and discount/gift voucher to the End User.
(470) Service: Centralized Policy Management
(471) 1. End User joins an insurance policy for CAR and HOME and LIFE through Mobile Data Capture or Vertical Insurance Portal.
(472) 2. End User accesses Insurance Portal and selects less expensive policy per policy segment:
(473) CAR Policy: policy cost will be reduced because of Pay As You Drive or other options.
(474) HOME Policy: policy cost will be reduced because of security functions at the home.
(475) LIFE Policy: policy cost will be reduced because of Personal Tracking or monitoring devices associated with the user.
(476) 3. Insurance Company will activate the control devices based on selected policy.
(477) 4. Insurance platform will be advised for each threshold exceeded in order to determinate the next fare to pay and will notify to End User.
(478) 5. For each client that earns a reward, the insurance company assigns virtual voucher discount to be used in purchasing new policy.
(479) Service: Fleet Management
(480) 1. A business operator monitoring the entire fleet joins the service to:
(481) Track each vehicle in real time (e.g., GPS position, speed, fuel, sensors)
(482) Manage theft/accident alarms
(483) Setup geo-fencing zones and manage the related warnings
(484) Support drivers in term of scheduling jobs, for example
(485) Obtain warnings when the truck is out of the defined target road/direction
(486) 2. A data transceiver present in each vehicle will send data in predefined time periods, allowing the M2M platform to produce the fleet management services.
(487) 3. SMS messages can be delivered to the entire fleet or to a single driver.
(488) Service: Proof of Delivery Automation
(489) 1. A logistic company delivers goods with its own fleet and it needs to certify/automate/digitalize each freight with a Proof of Delivery; each vehicle is equipped with an data transceiver, connected with vehicle sensors, a GPS antenna, a Digital Pen.
(490) 2. The driver ships the goods to the recipient and has the recipient sign the delivery document; the data transceiver sends data to the mobile platform.
(491) 3. The company back-office may:
(492) Monitor in real time the shipment (GPS position, status of the delivery)
(493) Watch/Validate/Forward the delivery document signed by the recipient with the driver's digital pen.
(494) Monitor Anti-Fraud Reports
(495) Monitor alarms/warning about driver behavior (average and max speed, accidents, and so on)
(496) Setup Geo-fencing zones for the fleet
(497) Service: Smart Shopping
(498) 1. End User subscribes to the service through Mobile Data Capture and/or Retailer site; after subscribing, End User receives an SMS for mobile application download and Retail Admin will provision a support application on the architecture 100.
(499) 2. End User will administer his own Home equipment to configure “shopping rules” to be visualized on his handset application.
(500) 3. End User at the Shop may then calculate the amount for the purchased products through a contactless interface on products and cash register contactless reader.
(501) 4. End User pays the shopping cart using Mobile Money Management contactless application on his phone and collects points on his loyalty card.
(502) 5. Retail Admin sends discount vouchers to End User phone.
(503) 6. End user accesses the reward catalogue in order to redeem the awards and spends any vouchers during the next shop visit.
(504) The following describes an exemplary implementation of the web console 266.
(505)
(506) The status report 2610 may display the number and percentage of devices in a functioning or normal status for the client, or other status data. The links 2604-2608 may be implemented as hyperlinks or other pointers. Upon clicking on a client link, for example, the web console interface 2600 may display a tree view object populated with the services provided by the architecture 100 to the selected client.
(507) The web console interface 2600 also provides a search interface 2612. The search interface 2612 accepts a search pattern, including wildcards, for finding resources managed by the architecture 100. In response, the web console interface 2600 finds matching resources and generates a search result interface 3802, such as that shown in
(508) The web console interface 2600 further includes a scheduled reports link 2614 that leads to a scheduled reports interface such as that shown in
(509)
(510)
(511)
(512)
(513)
(514)
(515)
(516)
(517)
(518) In
(519)
(520)
(521)
(522)
(523)
(524)
(525)
(526)
(527)
(528)
(529)
(530)
(531)
(532) The systems, modules, components and logic described above may be implemented in many different ways. The functionality may be implemented in a single system or functionally partitioned across multiple systems. As another example, the modules, components, systems, and logic may be implemented as computer-executable instructions or as data structures in memory may be stored on, distributed across, or read from many different types of machine-readable media. The machine-readable media may include RAM, ROM, hard disks, floppy disks, CD-ROMs, a signal, such as a signal received from a network or partitioned into sections and received in multiple packets communicated across a network. The systems may be implemented in software, hardware, or a combination of software and hardware.
(533) Furthermore, the systems may be implemented with additional, different, or fewer components. As one example, a processor or any other logic, module, or component may be implemented with a microprocessor, a microcontroller, a DSP, an application specific integrated circuit (ASIC), program instructions, discrete analog or digital logic, or a combination of other types of circuits or logic. As another example, memories may be DRAM, SRAM, Flash or any other type of memory. The systems may be distributed among multiple components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Logic, such as programs or circuitry, may be combined or split among multiple programs, distributed across several memories and processors, and may be implemented in or as a function library, such as a dynamic link library (DLL) or other shared library.
(534) The interface between components and systems such as the core SDP may include Transport Control Protocol (TCP), Real Time Transport Protocol (RTP) or other transport logic. The network gateway may route information based on Internet Protocol v4, v6 (i.e., IPv4 or IPv6) or other network layer protocols. The data link layer may include wired or wireless links, such as IEEE 802.11, WiFi, WiMAX, Asynchronous Transfer Mode (ATM), Fiber Distributed Data Interface (FDDI), Ethernet, or other data link layers over optical fiber, coaxial cable, twisted pair or other physical layers.
(535) Interfaces between the systems and the logic and modules within systems may be implemented in numerous ways. For example, interface between systems may be Web Services, Simple Object Access Protocol, or Enterprise Service Bus interfaces. Other examples of interfaces include message passing, such as publish/subscribe messaging, shared memory, and remote procedure calls.
(536) The hardware and software platforms that run in the SDP DS may vary widely. As examples, the endpoints may run the Windows CE™ operating system, JAVA ME™ system, Symbian™ operating system, Palm™ operating system. The hardware platforms may be implemented with a general purpose processing platform, such as those available from Sun Microsystems, Hewlett Packard, or International Business Machines and running Unix, Windows™, Linux or other operating systems.
(537) While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.