WO2012070960A1

WO2012070960A1 - Concentrator for networked sensors and remote meters, supporting diverse network access technologies with automatic fallback strategies, and sensor access security support

Info

Publication number: WO2012070960A1
Application number: PCT/PT2011/000011
Authority: WO
Inventors: Luís Miguel RIBEIRO TEIXEIRA; Mirones Victor Manuel Gutierres; Inês DE FREITAS OLIVEIRA
Original assignee: Portugal Telecom Inovaçâo, S.A.
Priority date: 2010-11-24
Filing date: 2011-04-01
Publication date: 2012-05-31
Also published as: PT105400A

Abstract

This invention relates to a concentrator for networked sensors and remote meters supporting diverse network access technologies with automatic fallback strategies and sensor access security support. It is basically characterized in that it comprises a software architecture of the stack to be implemented in the concentrator gateway, which includes three main software layers: - the sensor interface layer; - the transport network layer; - the core processing layer, these layers corresponding to the main three hardware blocks.

Description

DESCRIPTION

"CONCENTRATOR FOR SENSOR NETWORKS AND REMOTE COUNTERS, SUPPORTING VARIOUS NETWORK ACCESS TECHNOLOGIES, WITH AUTOMATIC RECOVERY AND ACCESS SECURITY STRATEGIES

TO SENSORS "

Scope of the invention

Current trends for basic service provider billing methods such as electricity, water and gas providers are generally based on remote monitoring and billing of customer consumption. This process is achieved by installing smart meters in the vicinity of the customer, which can be accessed remotely through a type of communication network, routing customer information to vendor data centers for further action.

In this context, the invention aims to provide a secure transport network for remote meter infrastructures by providing an original network interface at a point of trust and enabling the transmission of information over a proven medium. It also considers sensor domains for different customers, providing isolation and security for each information flow. The isolation between sensor domains and between them and the local access network is shown in figure 7.

Summary of the invention

The purpose of this document is to describe the software architecture of the stack to be implemented in Concentrator Gateway (CGW) and to explain some of its key features as well as how they solve or improve identified problems.

The present invention applies intelligent sensor networks and remote meter systems and is a multi-purpose control system that acts as a hub for sensor networks, including support for a plurality of different access technologies available, such as UMTS / GPRS, ADSL and GPON, supported on the operator network to access a central management system.

The present invention ensures complete transparency for the technology used, and it is possible to switch between technologies whenever a particular connection fails. In addition to having an interface with the central management system, the invention supports a web interface for local management (remotely accessible). Backup Mechanisms are also made available.

The core of the system is a processing unit responsible for completely isolating the sensor transport network or the sensor network. The processing unit has some intelligence, controlling the two-way flow of information and effectively isolating the management plan from the service provider side.

Software architecture closely follows hardware architecture. Three main software layers are considered, corresponding to the three fundamental hardware blocks: the sensor interface layer, the transport network layer and the central processing layer. Both hardware and software architectures ensure complete independence between different sensor networks or domains, accessible via the sensor interface layer.

The sensor interface layer comprises a variety of protocols and means, allowing transparent access to the sensor network, regardless of the underlying technology / protocol, and facilitating hardware upgrades while keeping said stack intact. The transport network layer comprises low-level controllers to handle the included access methods. Namely, this layer includes drivers for supported access network technologies.

The central processing layer concentrates intelligence, dealing with network scanning and recovery options. It has abstract interfaces for both sensor and transport network interface layers, allowing simple control of the integration of new services. The central processing layer defines data models for expected sensor readings and enables conversion of sensor interface layer data to common metrics and structure. This effectively simplifies the addition of new sensor types to the sensor network. The central processing layer provides identification of clients with active services. It usually gathers information from all sensors, with the sensor interface layer filtered for inactive clients, making it possible to distinguish the state of the client.

The software stack implements a complete abstraction with the hardware layers, enabling simple upgrades of sensor network technologies and coexistence of multiple sensor types and technologies on the same network, a problem often faced by service providers in rapidly evolving networks.

A difficulty for service providers implementing remote measurements is the integrity of the sensor network itself. It should not be possible to connect arbitrary sensors to the network by third parties and tampering with the sensors should be detected and reported to the service provider.

The present invention solves this problem by incorporating sensor logging and error checking into their readings with an alarm mechanism that communicates these problems to the service provider's data center.

Transport network reliability is ensured by a recovery mechanism implemented in the software stack, which automatically switches between access methods under certain interruption conditions. This also applies to sensor domains.

The software stack is modular and exports a complete set of Application Programmer Interfaces (APIs) to multiple subsystems, allowing service providers to build their own applications and services on the platform, reducing time to market for future applications.

Brief Description of Drawings

The following description is based on the accompanying drawings in which, without limitation, it is represented:

- In Figure 1, a schematic of the software architecture;

- In figure 2, the sensor interface layer;

- In figure 3, the transport network layer;

- In Figure 4, the central processing layer;

- In figure 5, the system management and configuration block;

- In Figure 6, the sensor authentication and hardware abstraction block; and

- In Figure 7, the isolation between sensor domains and between them and the local access network.

Detailed Description of the Invention

1. Software Architecture

CGW's high-level software architecture matches the hardware architecture specified in the CGW product description. There are three main software layers, aligned with the three fundamental hardware blocks as shown in Figure 1.

The sensor interface layer comprises low level controllers for access to the sensor network through different protocols and means. It also implements a hardware abstraction layer, providing a set of well-defined Application Programming Interfaces (APIs) that allow transparent access to the sensor network, regardless of the underlying technology / protocol.

This approach will simplify hardware upgrades in the sensor-side CGW software stack. Ideally, the inclusion of new hardware technologies in CGW on the sensor side will imply the inclusion of new controllers in the sensor interface layer and the updating of APIs to handle them, leaving interfaces for the rest of the stack unchanged.

The role of the CGW network side transport network layer corresponds to the role of the CGW sensor side sensor interface layer. It comprises low level controllers to handle the included access methods. In particular, the network layer of Transport includes GPON, GPRS / EDGE / UMTS and ADSL controllers. It also defines the APIs that control whether uplinks are active and the status of the various options. The decision to use an uplink, dealing with network scan and recovery options, is the responsibility of the central processing layer using the provided APIs.

The central processing layer concentrates all the intelligence of CGW. It includes interfaces to service provider management protocols and provides the platform on which services can be created in CGW. Interfaces to the sensor and transport network interface layers are abstracted to make it easier to handle new service integration.

The central processing layer defines data models for expected sensor readings and enables conversion of sensor interface layer data to common metrics and structures. This effectively simplifies the addition of new sensor types to the sensor network, leaving interpretation of the results to the service provider's data center.

The central processing layer also collects the information from all customer sensor networks enabling optimized collection management, distinguishing active and non-active customers, and the sensor interface layer should be inhibited for non-active customers. Features a management and configuration system with domain-specific sensor views of the global model available in the concentrator (which has the overall view of different sensor domains).

The complete configuration of the CGW is accomplished through the central processing layer, by remote access from the service provider's data center or locally by the technician at the installation site.

The concentrator for networked sensors and remote counters subject to the invention guarantees a clear and safe separation between the blocks (hardware and software) of the sensor interface layer and the transport network layer.

2. Sensor Interface Layer

The main purpose of the sensor interface layer is to enable the abstraction of sensor access technology from the rest of the CGW software stack. From a logical perspective, the layer includes the low-level drivers corresponding to the current CGW hardware revision, an internal adaptation, a control and configuration layer and defines APIs for use directly by the central processing layer. The sensor interface layer is shown in figure 2.

The sensor interface layer maintains an internal configuration layer, which in turn is configured by the central processing layer. The goal is to maintain an internal configuration of which sensors use a particular technology and what capabilities actually implement, while maintaining generic APIs and providing the appropriate internal checks.

An example is the setting of a sensor, when installed, as "read only" and cannot be consulted. Whether the central processing layer attempts to use an API to access the sensor in real time (possible in a scenario where the service provider may issue these requests from the data center without prior knowledge of the underlying technology of a particular sensor) , the sensor interface layer itself emits a signal indicating that the read information is not actual but rather the last known measure.

Another purpose of the settings layer is to maintain a database of authorized sensors in the CGW. Although registration of a new sensor is actually accomplished by the central processing layer, the sensor interface layer verifies that certain access is made to an authorized sensor.

An example is a customer attempting to connect a sensor to the existing network. With proper sensor configuration, although authentication at the central processing layer fails, it can be accessed remotely by the service provider with the correct API. In this case, the sensor interface layer emits a signal indicating that, although access is successful, the sensor is not actually part of the service provider's network.

The CGW will support by default the controllers for the following communication protocols: Power Line Communication (PLC), Zigbee, Wi-Fi, RS 232 and RS 585. Controllers for sensor domains are also integrated and may differ from access network drivers. Other drivers may be added in the near future.

The sensor interface layer is compatible with Δνδ and incorporates drivers for client network (s) network interfaces and supports isolation mechanisms that enable different domains or sensor networks to be supported by supporting different clients.

3. Transport network layer

The transport network layer is responsible for presenting a unified network interface to the central processing layer. Similar to the role of the sensor interface layer for the sensor side of the CGW, the transport network layer includes all the controllers needed to handle the choices of network uplinks present in a given CGW hardware version. See figure 3.

The transport network layer manages all interoperability issues with equipment already installed at the core of the transport network and keeps track of the status of each connection in an internal adaptation, control and configuration layer.

After the central processing layer properly configures the primary and backup network access methods, the transport network layer will maintain the current state of each option, opting for alternatives in the event of a breach of a higher priority choice.

The APIs provided by the transport network layer effectively isolate the central processing layer from the network access method used. However, the transport network layer exports APIs to verify which access methods are currently used and keeps track of network events for each simple access method. This allows the central processing layer to send the status of individual methods and possible service failures back to the service provider's data center.

The transport network layer is compatible with

IPv6.

4. Central Processing Layer

The central processing layer is the entry point for all CG functionality. Provides a system management and configuration interface for the service provider data center and authorized local users.

At a lower level, the authentication block of sensors and hardware abstraction handles software transactions with the sensor interface layer. Similarly, the network access and control block handles transactions between the central processing layer and the transport network layer. The central processing layer is shown in figure 4.

A well-defined set of APIs are exported to control the core functionality of the central processing layer for use by service applications and services. This is a logical space for building services and applications on top of the basic CGW software stack.

CGW core services are built on top of these APIs, but the service provider is free to create their own applications and services, taking advantage of the underlying software stack and the provided APIs.

The central processing layer includes a service scheduler to handle multiple concurrent service requests, and automated services that require CGW read or communication initiation. 4.1. Management block and system configuration

The system management and configuration block controls the configuration of the CGW software stack and the CGW hardware itself. CGW's central configuration consists of key and value data structures that reflect the hardware configuration of CGW. The block provides a web server for local configuration by authorized technicians and remote by the service provider's data center if the service provider wants to create its own management infrastructure. Alternatively, management can be done using management interfaces running on the central transport network, readily accessible by service providers.

CGW allows configuration of local accounts accessible via the local management web interface. These accounts can be set with different privileges, restricting access to specific services and applications. The system management and configuration block is shown in figure 5.

It is through this block that the service provider configures parameters such as which uplink interfaces are connected, connection priorities and recovery strategies, which services are currently which services are currently active, etc.

This is also the interface of registration of new sensors authorized in the network served by the CGW and of sensor type configuration and underlying access methods. This information will determine the configuration of the sensor authentication block and the hardware abstraction itself.

The data structures of the management and system configuration block are dynamic, allowing to extend the allowed configurations. Adding a new service to CGW, the service configuration must be inserted into this block, which provides a unified configuration platform for all services in CGW.

4.2. Sensor authentication and hardware abstraction block

This block handles logging, authentication, and all data requests to and from the sensor. It is shown in figure 6.

According to the inherited configuration of the management and system configuration block, this block enables a interface between the sensor interface layer with services and applications running on CGW.

As an example, if an electricity meter with a PLC interface is added to a sensor network, it will be configured in the system management and configuration block with the type "electricity" and "PLC" access. A global service configured in CGW to look up the values of all sensors would issue a request for this sensor, and the sensor abstraction and hardware abstraction block would route the request through the correct APIs to use the PLC interface. If another sensor were configured to use "Zigbee" as an access method, the block would use a different API to access the information. In both cases the service request would be the same, and the hardware would be completely abstracted from the service.

This block is also responsible for placing timestamps on all data to synchronize with the service provider's time reference. A service is configured on all devices to automatically synchronize the local clock with an NTP server running in the service provider's data center at regular intervals. Local time is maintained by a Real Time Clock (RTC) on the board chip. 4.3. Network access and control block

This block, according to the inherited configuration from the management and system configuration block, configures uplink connections with the transport network.

Its main purpose is to establish connections to the transport network using transport network layer APIs, and to perform connection status checking routines, optionally signaling the management block and system configuration in situations of abnormal behavior.

4.4. User Application Infrastructure

The user application infrastructure is an ecosystem where all non-core functionality runs. from CGW.

Applications and services have access to APIs from other layers / blocks to simply and safely provide all possible functionality in CGW hardware.

Registration of each application or service in the management and system configuration block is essential to ensure consistency in the software stack and to provide a unified control and management interface to the service provider.

5. Supported Services

The following sections describe services preinstalled on CGW using the user application infrastructure at the central processing layer.

Additional services and applications may be added by the service provider using the available APls.

5.1. Sensor reading on request

This is the most basic service that runs on CGW. The service provider may thereby have direct access to any sensor in the sensor network served by the CGW. Orders can be placed from the data center via the management and control interface or locally via the embedded management web interface.

Communication is established in question-answer mode, no non-persistent connection being established, with a simple measure occurring once.

Usage scenarios would simply serve to collect measurements from the sensor network at the end of the month for billing purposes. The periodicity of this process may vary as the requirements for collecting this information differ: the periodicity is configurable (specified for each counter) using a wide range (less than one second daily, etc); can still be requested (anytime).

5.2. Periodic monitoring and reporting

This service encourages CGW to start reading on a pre-configured group of sensors at specified intervals.

Readings are stored in the CGW's persistent memory, which can be accessed even after power outages or other critical errors.

The service may further be configured to initiate communications with the management interface in the service provider's data center after each reading, and report the readings directly.

A usage scenario would be to monitor readings once every hour to analyze consumption trends in a day or a week, helping consumers to choose the most cost-effective billing plan.

5.3. Real time detection

This service sets up a two-way channel between the service provider data center (or local management web interface) and the CGW. Sensors configured by the service will be read at maximum rates allowed by the sensor hardware and readings are immediately sent to the service provider's data center or local web interface.

This service is session oriented and due to potentially large amounts of data involved, no permanent storage space is provided in CGW.

A typical usage scenario would be where a customer claims a high electricity consumption. The service provider can initiate real-time meter readings and, by telephone or by interacting with home automation applications / services, force the customer to turn appliances on and off and check if a malfunctioning appliance is causing a problem, or if there is no problem at all. 5.4. Sensor Fault Detection and Reporting

This service periodically checks authorized sensors under the influence of the CGW, stores the latest readings and triggers the verification of the sensors.

If a sensor does not respond, or if a read value is inconsistent with previous values, a signal is emitted and the service contacts the data center of the service provider with an alarm indicating the sensor identification and its possible malfunction.

A usage scenario is where the consumer tamperes with the sensor and changes readings to lower values. When checking the sensor, this service would compare the reading with the previous one, verify that it is really inferior and send an alarm to it requesting the intervention of a technician.

5.5. User-configured alarm conditions

This service sets thresholds for a sensor, or group of sensors, that automatically alarm if a reading reaches these thresholds. When the alarm is triggered, this service initiates communication with the service provider's data center, and generates reports about the sensor that triggered the alarm and what alarm condition was triggered. ac ivada.

This is a cross-cutting condition for many services. This means that if a read by a monitoring and periodic reporting service crosses the set threshold, this service will activate the alarm and contact the data center in addition to the normal reports generated by the original service that triggered the read request.

A usage scenario is the customer service provider's permission to be notified as soon as a customer service limit is reached. Your service provider may use this service to set the threshold and rely on the remaining active services to eventually trigger the alarm as soon as possible, without additional weight to the system.

5.6. Uplink Data Encryption for Network

This service configures encryption in communication between the CGW and the service provider's data center.

This is independent of whether a secure connection such as https is used or not. This service directly encrypts the original data to be transmitted with an asymmetric key algorithm, PGP. Service configuration includes the public key to use in the encryption process. Only the service provider will have access to the private key to decrypt the information.

The user of one or more sensor domains has access to their information, with guarantees of isolation and protection of information.

Claims

1. Networked sensor and remote meter concentrator that supports various network access technologies with automatic disaster recovery strategies and sensor access protection support, characterized by having a stack software architecture that is deployed to the conversion port. and featuring three main software layers: - sensor interface layer; - transport network layer; - central processing layer, which layers correspond to three main blocks of hardware.

Network sensor concentrator and remote counters according to claim 1, characterized in that the sensor interface layer comprises various protocols and means for transparently accessing the sensor network regardless of the underlying technology / protocol and facilitating hardware upgrades by keeping that stack unchanged.

Concentrator for network sensors and remote counters according to claims earlier, characterized in that the sensor interface layer abstracts the sensor access technology from the rest of the software stack.

Concentrator for network sensors and remote counters according to the preceding claims, characterized in that the interface layer of the sensors includes low-level controllers corresponding to the current concentrator hardware revision (CGW), an internal abstraction, control layer. and configuration, and define application programming interfaces (APIs) to be used directly by the central processing layer.

Concentrator for network sensors and remote counters according to claim 1, characterized in that the transport network layer comprises the low level controllers for handling the included access methods and defining the application programming interfaces (API). to control which uplink is active and the status of the various options.

Concentrator for network sensors and remote counters according to claim 5, characterized in that the transport network layer includes the drivers for supported access network technologies.

Concentrator for network sensors and remote counters according to claim 1, characterized in that the central processing layer concentrates all intelligence as an entry point for all concentrator functionalities, providing differentiated system management interfaces; and / or query settings for both the service provider's data center (s) as well as for authorized local users to handle network verification and automatic disaster recovery options .

Concentrator for networked sensors and remote counters according to claim 1, characterized in that the central processing layer includes the interfaces to the service provider management protocols, provides a platform on which the controller services can be built, define data models for expected sensor readings, and address the conversion of data from the sensor interface layer to a common counter and structures.

9. Network sensor concentrator and Remote counters according to Claim 1, characterized in that the central processing layer has a sensor authentication and hardware abstraction block which handles software transactions with the sensor interface layer and a network and data access block. control that deals with transactions between the central processing layer and the transport network layer.

Network sensor and remote meter concentrator according to Claim 1, characterized in that the central processing layer collects information from all customer sensor networks allowing for optimized collection management, distinguishing active and non-active customers. that the sensor interface layer should be inhibited for non-active clients.

Network sensor and remote meter concentrator according to Claim 1, characterized in that the central processing layer has a management and configuration system with domain-specific sensor views of the global model available in the concentrator (which has the global view). different sensor domains).

Concentrator for network sensors and remote counters according to claim 1, characterized by the software stack implementing full hardware abstraction layers.

Network sensor concentrator and remote counters according to claim 1, characterized in that the software stack is modular and exports a complete set of interfaces to the application programmer for the various subsystems.

Network sensor concentrator and remote counters according to claim 1, characterized by a clear and safe separation between the blocks (hardware and software) of the sensor interface layer and the transport network layer.

Network sensor concentrator and remote counters according to Claim 1, characterized in that the sensor interface layer incorporates drivers for the interfaces of the customer's network (s).

Network sensor concentrator and remote counters according to Claim 1, characterized in that the sensor interface layer supports isolation mechanisms which enable different domains or sensor networks to be supported by supporting different clients.

Network sensor concentrator and remote counters according to claim 1, characterized in that the user of one or more sensor domains has access to their information, with guarantees of isolation and protection of information.