|
Wireless Sensor Networks & Complementary Technologies |
 |
 |
 |
|
Written by martcon
|
|
Tuesday, 29 December 2009 10:34 |
|
Wireless Sensor Networks (WSNs) have been spoken of since 2003 and in truth would have been expected to be more pervasive in 2009 than is currently the case. However, with initiatives throughout the world for smart infrastructure and smart cities it is reasonable to assert that WSNs will be a key technology driver for these initiatives. Energy saving programs, environmental considerations and the growing presence of what can be termed the 'Green' movement have created opportunities for WSN solutions in commercial buildings and in industries such as oil and gas and healthcare.
The capabilities of WSNs can be divided into that of measurement and detection. Examples of the former would be the recording of temperature, humidity and rainfall in a physical environment while intrusion detection and the detection of the presence of chemicals would be examples of the latter. It is the latter category which frequently requires more advanced capabilities than has been traditionally offered and in many instances requires a wireless sensor to have multimedia capabilties. The term 'Wireless Multimedia Sensor Networks' (WMSNs) appears to have been first coined by the Broadband Wireless Networking Lab at the Georgia Insitute of Technology (See http://www.ece.gatech.edu/research/labs/bwn/WMSN/). In essence, a WMSN is a network of wireless interconnected smart objects that can record multimedia content such as video and audio streams, images and scalar data from an environment.
The expansion of wireless sensors for the detection of multimedia content provides a richer realm of capabilities for WSNs. A WMSN can perform surveillance through the deployment of video and audio sensors to monitor an environment such as a public event or a private facility. Car traffic can be monitored to offer smart traffic routing advice to avoid congestion. Medical sensors can be integrated with 3G multimedia telecommunications networks to enable the monitoring of blood pressurce, breathing etc. of infirm or elderly patients while Machine Vision Systems (i.e. a system that can understand what is perceived visually) can be integrated with WMSNs to facilitate visual inspections and automated magnification for industrial process control.
To create a multimedia wireless sensor an audio and/or visual data collection module must be attached to a low-power wireless transceiver that is capable of processing and transmitting sensing video signals. Fortunately, hardware such as CMOS (Complementary Metal-Oxide Semiconductor) cameras and microphones have fallen in price in recent years to enable the creation of wireless sensors. A CMOS camera uses a CMOS-based image sensor chip which means that all required camera circuits can be integrated onto the same chip which in turn makes it possible to attach small cameras to constrained devices such as wireless sensors. This integration of video and audio technology with sensor networks enables the latter to provide richer content that was not feasible with the first wave of wireless sensors as audio, video, images, text and sensor signals can all be recorded and disseminated by a single WSN to provide a comprehensive analysis of a monitored environment. Using Vertoda, real-time analysis and interpretation of a situation can be performed and distributed to the rest of an organisation's software and systems.
There are a number of challenges that must be considered when discussing WMSNs. Multimedia content has a high bandwidth requirement which means that a multimedia sensor should have a high rate of data transmission. Power consumption is another key challenge. Multimedia data requires not only high transmission rates but also extensive processing. This is potentially a severe drain on the battery life of a multimedia sensor so protocols, algorithms and architectures must be designed with this challenge in mind.
Once the challenges of multimedia content recording are overcome, WMSNs can greatly enhance the capabilities of WSNs and open up new and complementary applications for diverse smart cities and smart infrastructure. There are however two other technologies that potentially complement WSNs and these must also be examined - GPS (Global Positioning System) and RFID (Radio Frequency Identification).
Given the diverse applications and the ad-hoc and frequently mobile nature of WSNs (for example, in emergency response situations) GPS would appear to be a natural complementary technology for integration within a WSN. GPS is integrated in sensor offerings by companies such as Crossbow (http://www.xbow.com). WSNs can be GPS-enabled by using GPS-enabled motes i.e. a GPS receiver attached to a wireless transceiver. This enables each node to be aware of its position relative to the network. However, making every sensor within a WSN GPS-enabled is not a cost-effective solution and may be impractical in enclosed spaces. For this reason, a number of GPS-free solutions have been proposed. In general, these alogorithms provide direction node localization based on the relative motion of neighbouring motes or the distances in the number of hops between nodes which thus obviates the need for GPS infrastructure.
Surprisingly, given that RFID and WSNs both fall under the branch of Computer Networking known as Pervasive Computing, relatively few attempts have been made to integrate the two technologies. In essence, RFID is a means of storing and retrieving data through electromagnetic transmission to an RF (Radio Frequency) compatible integrated circuit. It is typically used to label and track items in supermarkets and warehouses. Wal-Mart and Tesco, among many others, use RFID systems for management of their supply chains.
RFID tags can be categories as active, passive and semi-passive (or indeed, semi-active) tags. An active tag has a battery-powered radio transceiver whereas a passive tag operates without any battery. The latter achieves this by reflecting the RF signal transmitted to it from a reader or transceiver and adds its own data to the signal. Similarly, semi-passive tags use the radio waves of other senders as the energy source for transmitting their data. Unlike passive tags, however, semi-passive tags may have batteries to maintain memory or power other functions. It is not surprising to note that active tags are the most powerful RFID tags available given their larger range, memory and functionality but are also more expensive.
Sensing capabilities can be added to RFID tags using the same RFID protocols for reading the tag's ID. Tags will either have integrated sensors or will allow for adding additional sensors. A number of vendors are offering RFID tags with sensing capability. RFID and wireless sensors are natural complements for supply chain applications as the latter can be used for monitoring temperature in the chill chain and other situations where the recording of environmental conditions is imperative for the preservation of the goods being transported.
RFID readers can also be combined with an RF transceiver. Such a wireless device can sense environmental conditions and read IDs from tagged objects as well as transmitting this information to a data capture portal such as Vertoda. The integration of RFID into an ad-hoc WSN opens up many new applications. For example, a healthcare system that leverages RFID and wireless sensor technologies can monitor not only the patient's vital signs but also their medicine and pill bottles to track when a bottle is removed or replaced by a patient. Automated asset tracking and inventory management would also be facilitated by combining these two technologies.
We have referred to the use of WSNs for medical monitoring applications. WSNs that record conditions in the human body are commonly referred to as Wireless Biosensor Networks. In addition to monitoring the body, WSNs can also be secured using fingerprints or retina scans. The use of biometrics in WSNs is something we will explore in a coming blog.
WSNs have many diverse applications. However, it is only through the integration of WSNs with multimedia, GPS and RFID that WSNs can offer a comprehensive solution to meet all tracking and monitoring needs for smart cities and smart infrastructure. |
|
|
Using IP for Smart Objects & 'The Internet of Things' |
|
|
|
|
Written by martcon
|
|
Tuesday, 22 December 2009 14:26 |
|
Previously, we discussed Contiki, an operating system (OS) for Internet Protocol (IP) based wireless sensor networks (WSNs) and embedded devices. In this blog we will examine the use of IP for smart objects and 'The Internet of Things' in more detail.
A smart object is a small computing device that will also have a sensor or actuator as well as a means of communication - mostly, but not always, wireless communication. Smarts objects are embedded in other larger objects and systems including industrial machinery, car engines and lighting and heating systems. Smart objects are the technical drivers behind the smart ecosystems that are emerging in many diverse environments and applications and are the enablers of innovations in monitoring and automation for homes and industrial plants as well as the smart grid and energy efficiency systems. The potential application domains for smart objects is vast - from ad-hoc emergency response systems to smart transport infrastructure for urban areas.
The key property of a smart object is its capacity for bidirectional communication. Diverse measurements can be taken of environmental characteristics such as humidity, temperature, wind speed, pressure, vibration and energy consumption. In addition to measurements, the sensors in smart objects can also perform detection of elements in an environment such as pollutants or the presence of a chemical.
Smart objects are generally low-powered battery operated devices and will have a CPU and memory. Their form factor is small and the goal is that their price should be low - this was not always the case with wireless sensors but prices have lowered in recent years.
There are many protocols available for enabling wireless communication in a network of smart objects. Zigbee (http://www.zigbee.org) is a low-cost and low-power radio communications protocol based on the 802.15.4 standard for Wireless Personal Area Networks (WPANs). 6LowPAN (http://www.6lowpan.org/) also uses the 802.15.4 standard but uses IP with the aim of achieving the wireless 'Internet of Things'. 6LoWPAN stands for IP version 6 (IPv6) over Low Power Wireless Personal Area Networks. The IPSO Alliance (http://www.ipso-alliance.org) promotes this use of IP for smart objects and, indeed, there are many good arguments for using the existing IP protocol.
IP is an well-established open standard and is media independent which means it can run over low-powered radios such as 802.11 WiFi, long range 3G (Third Generation) telephony as well as ethernet among others. Best effort or reliable transmission is available using UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) respectively. Recent implementations such as uIP have shown that IP is a lightweight protocol and its versatility means it supports any type of application and in turn is supported by a diverse range of devices from high-end servers to smart phones. This versatility has led to IP's ubiquity and over its comparatively long life its has showm itself to be stable (after all, it is used for the Internet), manageable (using protocols such as Dynamic Host Configuration Protocols - DHCP, Domain Name System - DNS and Simple Network Management Protocol - SNMP) and provides end-to-end communication.
These cogent arguments are made by the IPSO Alliance to advance the case for using IP in smart ecosystems. IPv6 is used in particular as it contains a number of optimisations for constrained devices, a category in which most smart objects will find themselves due to their unavoidable processing and memory limitations. Stateless compression of IPv6 headers is possible which means that smart objects can communicate with their neighbour in this compressed form. Packets can be fragmented and neighbouring smart object nodes can be discovered. The Internet Engineering Task Force (IETF) has defined these properties in the 6LoWPAN adaptation layer.
IPv6 was designed to counter the ever dwindling number of unallocated IP addresses. Its key feature is that it expands the IP address space from 32 to 128 bits. The development of IPv6 was vital as the number of computers will ultimately be far outstripped by networked devices and smart objects. A number of features has also been introduced to improve performance. The size of the Maximum Transmission Unit (MTU) has been increased from 576 to 1280 bytes and fragmentation is now implemented at the endpoints rather than in intermediate routers. A scoped multicast for broadcasting to all hosts with a multicast group is also included.
Despite these improvements, supporting IPv6 over LoWPAN networks is not a straightforward task as the frames used in LoWPAN are approximately one-tenth of the size of IPv6's minimum MTU which makes fragmentation and compression mandatory. Furthermore, the 802.15.4 standard upon which LoWPAN is based is low-power and low-throughput and is prone to failures and interference. Finally, a LoWPAN network is a mesh network of short-range connections which is contrary to the expected typical IPv6 architecture. It is for these reasons that the 6LoWPAN working group was established by the IETF. 6LoWPAN defines how IPv6 communication is transported in 802.15.4 frames. In addition to the optimisations in fragmentation and header compression described earlier, 6LoWPAN supports layer-2 forwarding between the link-level addresses of the end of an IP hop.
Despite the development of the 6LoWPAN format specification, implementation was not considered by the IETF working group. There are also a number of issues that must be considered for LoWPAN environments. There are typically a large number of devices that are embedded in the environment or infrastructure and so cannot be moved to improve communication. Multi-hop routing is therefore used to extend range and avoid the many obstacles that can be present in an environment. Link quality can also be variable due to interference and environmental factors. Effective routing is thus a necessity in such a situation. Moreover, certain applications may require device mobility. In many cases, the devices may not be moving a particularly long distance but do respresent a change in the LoWPAN's topology. Power management is not comprehensively defined in the 802.15.4 specification but must be considered for routing in commercial applications.
One issue to note when considering IPv6 over LoWPAN is Mesh-Under (Layer 2) and Route-Over (Layer 3) Forwarding. With mesh-under the forwarding and routing of packets within the LoWPAN is carried out at the adaptation layer and no IP-routing takes place at the network layer. Route-over performs routing at the IP layer and each smart object node serves as an IP router.
The number of smart objects in a LoWPAN is potentially vast. Each of these objects will require an address. Again, the IPSO Alliance argues that the easiest mechanism for doing this assignment and connecting these nodes to each other is to use IPv6. IPv6's Neighbour Discovery (ND) Protocol is used to resolve and automatically configure addresses as well as to discover routers and determine the reachability of neighbours. The IETF 6LoWPAN working group is currently working on ND optimisations for 6LoWPAN environments. The considerations the working group has to take into account include the continously changing wireless link. the often lengthy sleep mode of the networked devices, the battery and processing constraints of the devices and the often mobile nature of the nodes. In essence, the 6LoWPAN ND Protocol extends the standard IPv6 ND Protocol and has added functionality to take mobility and fault tolerance into account. The final protocol will support both Rroute-Over and Mesh-Under networks.
There are a number of alternatives to using 802.15.4 for smart object communications. The use of low-power Wi-Fi and Broadband over Powerlines are other possibilities.The latter is particularly attractive as it uses the existing electricity network which means that a computing device can be networked by plugging it into any electrical outlet. No matter the physical medium used for transmission, however, IP would appear to be the appropriate choice for carrying the data generated by smart objects. Otherwise, the consequent loss of standardisation between LoWPANs would necessitate protocol translation gateways to enable different networks to communicate with each other. Given the predicted explosion in smart objects and networks in the coming years, this is an expensive and unattractive proposition from both a technical and financial perspective. |
|
An Operating System for 'The Internet of Things' |
|
|
|
|
Written by martcon
|
|
Tuesday, 15 December 2009 14:30 |
|
TinyOS (http://www.tinyos.net) is the original and probably best well known operating system (OS) for the sensor nodes that make up Wireless Sensor Networks (WSNs). Sun Microsystems has also developed Java based sensors using the Squawk Virtual Machine (See https://spots.dev.java.net/). However, there is another operating system that we must consider not only for WSNs but also for embedded devices generally and what is sometimes referred to as 'The Internet of Things'.
The Contiki Operating System (http://www.sics.se/contiki) is an open source multitasking operating system for memory-constrained networked embedded devices and wireless sensor nodes. It is a well established OS. Version 1.0 was released in March 2003. The latest edition, Version 2.3, was released in June 2009. It is free to download under BSD license. It was developed jointly by several research and commercial organisations including the Swedish Institute for Computer Science (SICS), the Technical University of Munich, SAP, Cisco and the semiconductor manufacturer ATMEL.
Contiki has been ported to many of the vast range of sensor products available including Crossbow's TelosB and MICAZ sensor motes as well as this vendor's Environmental Sensor Bus (ESB) (See http://www.xbow.com). Atmel's AVR Raven sensors (See http://www.atmel.com) and Sentilla's JCreate prototyping platform (http://www.sentilla.com) are also supported.
The key feature of the Contiki Operating System to note is that the OS provides Internet Protocol (IP) Communication, both for IP version 4 and version 6 (known as IPv4 and IPv6 respectively). This has major implications as Contiki makes IP-based sensor networks possible. Contiki's uIP embedded TCP/IP stack was released in 2001 and is the world's smallest IP stack taking up 5k ROM for IPv4 and 11k ROM for IPv6. uIPv6 is the only certified IP stack (certification was achieved in October 2008) for embedded systems while uIPv4 is used in diverse applications including container tracking systems, oil pipelines, car engines and satellites.
One could argue that TCP/IP is unsuited for sensor networks because of the extreme communication conditions that sensor networks exhibit. However, there are a number of techniques which can be used to make IP-based Sensor Networks feasible. Spatial IP Address assignment can provide semi-unique addresses to sensor nodes. Application overlay networking lets distributed applications run on top of the network and decide how to process the packets. Distributed TCP caching lets sensor nodes assist each other so that neighbouring motes are able to retransmit segments that are lost due to errors on the radio channel. Finally, header compression reduces the header overhead to only a few bytes for messages carrying sensor data.
In addition to these benefits, Contiki also provides a low-power MAC (Media Access Control) layer and preemptive threads that run on top of events. Contiki provides support for both multi-threading and what are termed 'protothreads'. Protothreads are lightweight stackless variants of the threading used in computer programming and are designed for severely memory constrained systems such as wireless sensor nodes or other small embedded systems.
From the perspective of the programmer, Contiki is written in the C programming language so knowledge of C is a more than sufficient starting point for getting started with the OS. Loadable modules are used to implement the different facets of the OS. The build system will also be very familiar to C programmers who regularly program on LINUX or UNIX platforms as applications can be compiled for different hardware or simulation platforms by using the standard 'make' command with different parameters.
In addition to uIP, Contiki also provides a lightweight communication stack for low-powered radios called Rime. Rime provides a number of communication primitives from best-effort local area broadcast to reliable multi-hop bulk data flooding.
IP-based sensor networks enabled by Contiki have been deployed in diverse projects. Examples include remote water monitoring in the Baltic Sea, locating vehicles and people in road tunnel fires (this is part of the Runes project. Runes stands for Reconfigurable Ubiquitous Networked Embedded Systems. See http://www.ist-runes.org/ for more details.) and in surveillance and intrusion detection applications. Commercial users include ABB, BMW, Cisco, NASA and General Electric.
Give the open and ubiquitous nature of IP, it is an ideal candidate for networking pervasive devices. Contiki and uIP have played a major role in demonstrating the potential of using IP in these diverse, often constrained networked devices. What are termed 'Smart Objects' are evolving all the time. Roughly, Smart Objects can be categorised as sensors, actuators and smart meters. These devices are the enablers of the smart grid, smart cities, home vnd building automation, asset tracking and utility metering. Connecting these smart objects is a major issue and IP would appear to be by far the most suitable protocol for what is termed 'The Internet of Things'. To promote the use of IP for the Internet of Things Cisco, Ericsson, SAP and others founded the IPSO Alliance (The IP for Smart Objects Alliance) in October 2008 (See http://www.ipso-alliance.org). IPSO seeks to extend the use of IP for resource-contrained devices over a wide range of radio technologies.
Extending IP to low-power, wireless personal area networks (LoWPANs) that typically make up a smart object network was once considered impractical and many vendors used proprietary protocols. However, 6LoWPAN has altered this perception as efficient IPv6 communication over IEEE 802.15.4 LoWPANs is facilitated. It can be argued that uIP was the pioneer for protocols such 6LoWPAN and was the first technology to make the Internet of Things possible.
Contiki is not the only WSN OS that offers IP Networking. TinyOS was relatively late in offering IP networking but this capability finally became available in 2007. IPv6 networking is now possible using TinyOS but the OS is not yet certified as IPv6 ready. A 6LoWPAN and IPv6 stack has been implemented. IP-based sensor networks and smart objects will become ever more prevalent in the coming years so an implementation was vital for TinyOS to remain relevant. |
|
|
Building Management Systems |
|
|
|
|
Written by martcon
|
|
Monday, 07 December 2009 14:04 |
|
Figure 1: A Building Management System is key enabler of a 'Smart' or 'Intelligent' Building.
A Building Management System (BMS) (also known as a Building Automation System or BAS) is a control system that is used to control and monitor equipment so as to manage lighting, ventilation, heat, power, security and fire detection.The application domain of a BMS is very broad in scope and can include boiler room, pump and plant control, underfloor heating control, heat recovery systems and general process control. A BMS consists of hardware and software. Hardware will be used to control the equipment while instructions to these hardware components will be issued from a software system.
The common controls for equipment would be manual switches, time clocks or temperature switches. The purpose of a BMS is to automate these operations as much as is practicable. A BMS can be used for all kinds of buildings but would be most common in a manufacturing plant. Generally, the BMS will store a number of pre-set requirements for the building and controls the connected equipment to meet these requirements.
The hardware requirements for a BMS are diverse. Sensors including wireless sensors can be used to monitor temperature, humidity and even whether a room is occupied. Smart Meters can be used to monitor the use of resources such as gas, electricity and water. These devices can be controlled using Vertoda or can be interfaced with actuators to control mechanical moving parts. Heating, Ventilation and Air Conditioning (HVAC) systems are generally controlled by SCADA (Supervisory Control and Data Acquisition) systems for coordinating operations. Distributed Control System (DCS) are complementary to SCADA systems in that they control operations and processes using a PLC (Programmable Logic Controller). Indeed, a Building Management System can be seen as a particular example of DCS technology in action.
The PLC or actuator is just one example of an equipment controller that can be used by a BMS. System and terminal controllers are also available. In essence, these devices send control signals to the equipment to modify their calibrations or turn themselves on or off. Software is required to interface with these PLCs remotely and in many cases with non-PLC sensors and meters as well. One can see, therefore, that the diverse equipment and consequent standards means that a BMS is a complex platform from a software perspective that will require many monitoring and control components for different equipment, buildings and conditions.
Generally, special protocols are used for BMS but this is beginning to change. BACNet (http://www.bacnet.org) is a data communication protocol used for building automation and control networks that was developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers. Lonworks is a platform created by Echelon (http://www.echelon.com) for enabling the creation of networks using devices that transport their data over diverse media such as twisted pair wire, power lines, fiber optics and RF (Radio Frequency). Modbus (http://www.modbus.org) is a open communications standard that is often used in SCADA systems. While these standards are quite specific in their intent we are beginning to see web protocols such as SOAP (Simple Object Access Protocol) and XML (eXtensible Markup Language) being used by BMS. As explored in a previous blog, different protocols are used to capture smart meter data while Zigbee is the prominent communications protocol used by Wireless Sensor Networks (WSNs).
The key tasks of a BMS is monitoring and controlling equipment within a building or plant and providing reporting functionality on the performance of this equipment. A BMS can be used to detect equipment and plant faults, dirty or used filters as well as abnormal occurrences. A BMS can also provide details of energy consumption by different equipment and by different processes and operations that take place within the building. The results of energy saving initiatives can also be monitored with the BMS as can the consumption of gas, electricity and water. Measurements can be taken of different environmental conditions within the building such as temperature, humidity and air quality. Occupancy patterns of a building can also be monitored by a BMS and can assist in operational decision making regarding equipment.
Using the diverse hardware and communication technologies available a BMS can control all equipment within a building. Loads such as chilled water pumps can be turned off when not required. Lights and lifts can be turned off when the building is unoccupied. Peripheral controls such as occupancy sensors can relay this data to the BMS which in turn can send a control message to other equipment. A BMS can also play a key role in energy management by enforcing policies to reduce energy use during times of low occupancy e.g. automatically turning lights off when a room is unoccupied, turning off the air air conditioning overnight etc.
A BMS can be integrated into one unifed system with CCTV, Access Control, Energy Management and other voice and data systems to provide an overall system for managing building-wide operations. Data can be shared between these systems for security purposes and for detecting events such as fire in an isolated part of the building. A BMS is then a key component in what is often termed an Intelligent or Smart Building.
Given the myriad of equipment that needs to be monitored and controlled, many software systems can be required to make up one overall monitoring system. Vertoda can provide data capture and management for smart meters and wireless sensors among others. The latter devices in many cases are cheaper and more flexible alternatives to traditional sensors. The data captured by Vertoda is available to the other components of the Smart Building including the BMS. The fault management, Business Intelligence/Reporting and device management functionality of Vertoda can all be integrated into one unified solution for managing and controlling a plant or building with the consequent financial, security and energy saving benefits outlined above. |
|
Last Updated ( Monday, 07 December 2009 16:39 )
|
|
Smart Meters 101 Part 3: Management & Issues |
|
|
|
|
Written by martcon
|
|
Monday, 30 November 2009 15:23 |
|
We have previously examined the types of smart meters that are available i.e. electricity, water and gas. The next question to examine is how this vast new pool of data can be managed by a utility or indeed by an organisation that has installed smart meters on their premises themselves.
The Information Systems used to manage smart meters are typically referred to as Meter Data Management Systems (MDMS) . MDMS capture data from multiple metering systems and can then supply that data to the other Information Systems within the organisation for purposes such as billing, maintenance, forecasting and customer service. Like Enterprise Systems, MDMS have a central database that stores all customer, meter and reading data. The different Information Systems that require this data can interact with the MDMS using an Application Programming Interface (API). Alternatively, the data can be pushed from the MDMS using data export functionality.
It would be impossible for organisations and utilities to reap the cost and consumption saving benefits that an energy management strategy enabled by smart meters would provide without using an MDMS. MDMS can manage outages by recording start and restore times and organise outage events by meter, grid or customer. MDMS can provide fault management functionality and notify other Information Systems such as Outage Management Systems of alerts. The pool of data provide by an MDMS can be combined with other data such as weather information to predict how a grid might perform under extreme weather conditions and can serve as a basis for developing distribution planning and reliability strategies. And, of course, as smart meters provide data of energy consumption the data captured by MDMS ultimately is used to measure revenues for the utility.
MDMS are a key component of what are referred to as Advanced Metering Infrastructure (AMI) systems. AMI refers to the entire chain of technologies that enable the smart grid. These include not only the MDMS but also the smart meter equipment and the communications used to relay the data readings to the MDMS. AMI gives the utility company control over all aspects of the smart grid.
Vertoda can act as an MDMS as it provides device organisation, fault management and Business Intelligence capabilities to capture data from smart meters and transform that data into meaningful information that the utility organisations can use for business decision making. This information is then available for the ERP, Business Intelligence and other Information Systems of the organisation. Furthermore, given that Vertoda can manage devices such as RFID, Wireless Sensors and GPS in addition to smart meters our system can act as comprehensive middleware to manage all the devices used to enable smart infrastructure.
There are a number of issues which must be considered in relation to smart meters and the smart grid. We have previously noted that the security of smart meters is a problem as the vast majority of devices do not encrypt or digitally sign the data they generate. The possible solutions for smart meter security would be to encrypt or sign the data at the device level or to transfer the data through a secure communications link. This is a vital issue as without security there is nothing to prevent consumers being maliciously disconnected or having their consumption data hacked and modified.
A related concern is that of privacy. Some claim that meters record readings so often that power flows can be interpreted to reveal consumption behaviour and even use of individual appliances. Some even fear that consumers will in the future be cited for excessive use of resources through the monitoring of their smart meter. Many US states such as the Colorado Public Utilities Commission have initiated inquiries into the privacy implications of the use of smart meters. The Dutch parliament recently rejected a bill that would have compelled all citizens to have a smart meter installed in their home. In Britain, The Department for Energy and Climate Change (DECC) says that there is theoretically scope for using the smart metering communications infrastructure to enable a variety of other services such as the monitoring of vulnerable householders by health authorities or social services departments.
The invasiveness of technology is always a concern and is not confined to smart metering. Finding a solution that would alleviate concerns will be difficult to achieve. However, one step in the right direction would be to encrypt the data in transit and secure the raw consumption data in the database it is stored in so that the 'public' view of the information is the billing information generated using this raw data. Vertoda can offer a solution to secure the smart meter data both in transit and in storage.
We have alluded above to the transmission of smart meter data. This is another difficulty for smart meter users as currently there is a lack of standardisation in data transmission. One mechanism by which data transmission can take place is by using mobile network systems such as GSM (Global System for Mobile Communications) using SMS/text message, GPRS (General Packet Radio Service) , CDMA (Code Division Multiple Access) or 3G (Third Generation). Of course, this assumes that the smart meter is in a 'good cell area' and is subject to vulnerabilities in the mobile transmission of unencrypted data. Radio transmission in a licensed or unlicensed band is another possibility but has wireless security issues. With RF Mesh (the RF stands for radio frequency), each smart meter essentially acts as a router and forwards the data to an Access Point or hub which will then send the data to a utility using a mobile network or land line. The other alternative is to configure the smart meter to communicate with a radio tower which will in turn forward the data to the utility's IT systems.
Power line transmission is another option. Broadband over powerline, also known as power line networking, enables Internet connections with the home through existing electricity transmission and distribution lines. A power line modem has recently being developed by On Semiconductor (http://www.onsemi.com) for this purpose. For the utility company, the most logical option would seem to be the transfer of data from the smart meter through the power line as the infrastructure is already in place and it would be a standard mechanism for transferring data. The lack of a standard mechanism by meter vendors for data transfer is a challenge for utilities as otherwise they have to capture data from diverse mobile and radio systems, a functionality that can be provided by Vertoda.
The development of data transmission standards is still evolving. The Spanish utility, Iberdola (http://www.iberdola.es), has initiated the PRIME project to develop an open standard for powerline communication. Echelon (http://www.echelon.com) have developed a similar standard. Power line transmission and the use of mobile networks appears to be more popular in Europe than the US where RF Mesh and tower-based smart meter communications appear to be more prevalent.
Similarly there's a lack of standardisation in terms of access points. Access Points can communicate using radio, mobile or power line communications. Some smart meter vendors offer data concentrators which forward data to the utility through an IP network.
Within the home, communication will also take place between the smart meter and the consuming appliances. Zigbee started to gain traction in smart meter to appliance communication in 2007 and has been adopted by many smart meter vendors. WIFI and WIMAX are other possiblities for wireless communication within the home but Zigbee appears to be the most likely standard given its adoption by so many leading vendors.
Unsurprisingly, there are many vendors of smart meters including EnergyICT (http://www.energyict.com), Iskraemeco (http://www.iskraemeco.co.uk), Echelon (http://www.echelon.com), GE (http://www.ge.com) and Landis & Gyr (http://www.landisandgyr.com). Most of the leading software companies have strategies in place for the smart grid. Google has developed their own power meter, SAP and Oracle offer solutions in this area and Microsoft and IBM have 'green' strategies in place that take the smart grid into account. The value proposition offered by Vertoda in the smart meter arena is one of data and security management. Vertoda can both acts as middleware and provide the security framework required for encrypting both data in transit and in storage. |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 6 of 19 |
|
