M2M ENABLING A GENERIC DEVICE

Transcription

1 The BITX papers A Rel 1.0 Last revised on 18 July 2007 M2M ENABLING A GENERIC DEVICE White Paper Authors: Mauro Macchi Chief Technology Officer Nicola Scardi Marketing Director 2007 Your Voice S.p.A. Milano, Italy

2 Content Table of contents Copyright Notice INTRODUCTION Is M2M really new? The potential of M2M A TYPICAL M2M INFRASTRUCTURE M2M ENABLING Retrofitting an existing device Embedding a BITXml driver into a generic device The BITXml driver: a closer look A generic microcontroller A few introductory notes on the BITXml protocol main features Frequently Asked Questions

3 Copyright Notice Any intellectual property rights pertaining to this document are the property of Your Voice S.p.A., Milano Italia. Unless differently stated on its cover, the present white paper can be freely downloaded and circulated, provided it is maintained as is and is not amended, cut or modified in any of its parts. Your Voice S.p.A. reserves the right to change the present conditions in any moment, for any reason and without prior notice. 1

4 Chapter 1 Introduction A definition of M2M and a brief analysis of its potential. T he term M2M (machine to machine) has lately become a widely accepted substitute for telemetry, remote management and in more general terms it is used to describe any type of two-way communications system between geographically distributed generic devices and a centrally managed software application (typically running on a server or personal computer) Figure 1 A generic M2M diagram: users can connect via web browser (1) to a centrally managed application (2) and check the status or position of geographically distributed assets (3). Is M2M really new? The concept of telemetry and remote management of distributed assets is not new. Since many years, several companies have been developing SCADA (Supervisory Control And Data Acquisition) infrastructures, as a means to collect data from remote equipment and facility systems in various fields, especially in the industrial automation, public utilities and energy sectors. On a first surface evaluation, one could be led to conclude that M2M and SCADA are exactly the same thing: they exploit the connectivity of generic equipments in order to establish a link between these and a specific software application. But there are differences. 2

5 When the first SCADA systems were deployed in the absence of universally accepted standards and reliable public networks - engineers were almost forced to design and maintain proprietary wired / M2M and SCADA share the same goal, but they belong to different technological eras. wireless networks and protocols, thus creating a series of rigid and closed communications infrastructures. Modern M2M technologies were born under a totally different scenario: internet and cellular networks have become a worldwide standard, with unprecedented levels of coverage, reliability and affordability; smaller and smarter devices are constantly flowing to the industrial and consumer markets, making it easier to conceive and provide new post-sale and remotely managed services; software design and systems interoperability standards like xml, web services and SOA are converging to create fertile ground for M2M communications technologies, making it easier to apply them horizontally across different industries, with a much lower capital expenditure versus the past. The potential of M2M It is not the purpose of this document to present market estimates and growth projections, but we feel it is important to mention some of the facts that are generating such a great interest around M2M communications technologies. Everything is getting connected. Any company can Thanks to real-time remote access and the availability of information access real-time information on that wasn t accessible or too expensive to collect in the past, it is now its products anytime, possible to manage complex business processes with a higher degree anywhere. of efficiency and make decisions that can produce positive impacts on any company s results. Everything is getting connected: expanding wired-wireless networks are enabling communications between people, machines and devices. By connecting sensors, air conditioners, trucks, vending machines, factory machines, these can communicate with remote control centers and allow higher-order services such as remote diagnostic and status monitoring, usage tracking, consumable replenishment, geo-localization just to name a few. At the heart of this revolution is the possibility for a company to access real-time information anytime, anywhere on its products and provide top quality services without limitation of time and distance. When talking about potential, the following comparison can be extremely effective: if the number of worldwide mobile handsets has reached the considerable figure of 2 billion units, the number of "machines" potentially affected by M2M could well be in excess of 30 billion units. 3

6 Figure 2 A comparison between the number of mobile phones and a conservative estimate of the number of machines potentially affected by M2M. All this said, it s no wonder many analysts share the idea that the M2M silent revolution could represent as big an opportunity as the whole PC era. 4

7 Chapter 2 A typical M2M infrastructure What is the least common denominator of any m2m infrastructure? Or: what are the main architectural elements of a generic remote asset monitoring and management application? A nyone who has an interest in the concept of m2m will sooner or later be presented with a diagram similar to the one below. Figure 3 The main elements of a generic M2M application. 5

8 What is the least 1 The first element of an M2M infrastructure is the M2M common denominator of application (in simplistic terms, the front-end, or user any M2M architecture? interface). This is typically a client-specific development The answer is in 7 and may be represented by a simple web interface, through which an end-user can monitor and control the devices under his responsibility. In other situations, the M2M application can take the form of a complex, multichannel (Web, Voice, SMS, PDA), multi-user, administration and control system, where every aspect of the entire process (remote assets administration, user profiling, permission rules and system configuration) can be under control. 2 The second block certainly the most important is the M2M middleware, often defined as the brains of the entire M2M infrastructure. It s the middleware that translates raw machine data into information companies can use to improve their processes and make decisions. In principle, the more a middleware is flexible and quickly adaptable to the countless types of devices and application requirements, the more it will be useful to those involved in the end-to-end machine-to-machine application development process (end-users, application developers and system integrators across different industries). 3 Unlike SCADA, Modern M2M applications can leverage wide-coverage, cost-effective wireless and internet commercial networks as an incredible booster for M2M adoption. Thanks to the availability of reliable and affordable public communication networks, M2M can now be applied across many different industries, with a much lower investment. The M2M gateway act as an interpreter, translating asset-specific data into usable information and making it available for the external world. external box or an internal module containing: 4 No matter what means of transport has been selected, the fourth fundamental element in an M2M infrastructure is the Gateway, i.e. a particular hardware / software combination that makes the remote asset - such as an automatic vending machine, for instance - accessible to a centrally managed control system. A typical example of M2M Gateway is represented by an A networking component, such as - for instance - a GPRS modem A variable set of I/O interfaces for the connection with the local device (serial ports, analogical / digital ports) A software component called the Gateway Manager which acts as an interpreter between the middleware (2) and the remote asset (5). In particular, the Gateway Manager is the critical software component that makes it possible to convert and execute instructions based on a generic (better if open) m2m protocol (6) into proprietary, intelligible, asset-specific commands. In other cases, when user interface is important, the M2M Gateway can be represented by a desktop PC or a handheld computer. The M2M Gateway is the key to understanding the concept of M2M enabling and the differences that exist between the two main methods that will be discussed ahead in this paper: retrofitting and embedding. 5 These are the over 30 billion machines mentioned in the introduction. Elevators, Vending Machines, HVAC units, widely-used industrial components such as motor drives, PLCs or UPS (Uninterruptible Power Supply) units, pumps, tanks, electric towers and lines, railways, RFID tag readers, moving assets such as vehicles, trucks, trains, containers. In 6

9 principle, any piece of equipment that is productive and remunerative to manage and monitor from a central control room is a good candidate for M2M. In general, missioncritical assets, especially when covered by servicing and maintenance contracts, will be positively affected by the improvements in efficiency, downtime impact and servicing cost, deriving from M2M adoption. Choosing an open (public) M2M protocol is important if you don t want to bind yourself to a specific M2M application. 6 The sixth element in an M2M ecosystem is the communications protocol which is at the foundation of the Middleware-Gateway data transmission (see points 2-4 in Figure 3). Selecting the right Middleware-Gateway communications protocol might not seem a strategic matter at first sight, but this decision can produce important consequences when the device is installed and someone has to figure out how to link it to a telemetry / remote control system: choosing an open protocol is the best guarantee that you will not bind yourself or your customers and business partners to a specific proprietary software application, thus maintaining a broader range of options. In coherence with this line of reasoning, the authors of this paper support an open (public), XML-based communications protocol called BITXml ( BITXml s declared ambition is to provide a response to the issues faced by OEMs, application developers and system integrators when dealing with the complexities of infinite proprietary protocols, designed for a single microcontroller s intrinsic features. Thanks to BITXml, it will be possible: To encapsulate the relevant commands of a particular device, and transport them from a server application to an external Gateway Manager, where they will be translated and routed to the device (the encapsulation is made server-side, while programming the Middleware). If the device has been designed to incorporate a BITXml driver, it will be possible to transport BITXml commands through the available connection and straight to the device. In other words, when embedding a BITXml driver, there s no need to encapsulate and transport proprietary commands, but the Middleware can be programmed via a custom BITXml syntax, which guarantees greater simplicity and higher expressivity standards vs proprietary binary protocols. Once more, we re talking about the same two options when it comes to M2M enabling a generic asset: retrofitting as opposed to embedding. 7 The last point needs very little explanation. Any product engineer know too well what kind of variability does exist in the number and type of commands that one need to send to a specific port of any given device (serial, analogical, digital, TTL ) in order to obtain a specific response. If the device once deployed will need to be part of a centrally managed network of (potentially) heterogeneous devices, than embedding a BITXml driver could be a far sighted move. 7

10 Chapter 2 3 M2M enabling There are essentially only two options available, when it comes to M2M enabling a generic asset: retrofitting or embedding. I f seen from an OEM s or (up the value chain) a chip manufacturer s perspective, the two options mentioned above are in fact even more simplified to the following two: To do absolutely nothing. Someone (if ever) will bear the burden of retrofitting my products and deal with time-consuming, complex and low-level communications protocols, when it comes to developing a remote monitoring application. To plan ahead, share the view that everything is going to be connected, therefore my products will be no exception and start evaluating the possibility to incorporate into my product design a universal software driver that will make them future-proof and M2M ready. We re teasing the reader a little bit of course, but after all it s the ambition of this Paper to highlight the advantages of the second of the two options described above. For the sake of completeness, we will describe in short the idea of retrofitting, saving all our efforts (and the reader s) for what we consider the most important objective of this document: To describe the simple principles and advantages behind the idea of embedding a BITXml driver into virtually any type of electronic device, thus making it ready to be linked depending on the available connection to a generic central monitoring and managing application. 8

11 Retrofitting an existing device As already seen in chapter 2 (ref. Fig. 3), the usual way to M2M enable an existing generic device (say a vending machine or an elevator) is by connecting an additional M2M box to its serial port. This box is usually a specialized hardware / software combination including: A generic processor, where a Gateway Manager Software (the S element in Figure 4) will run. If BITXml is the chosen communications protocol, this software component will translate the XML instructions received from the server into commands the asset (5) can understand. A networking module or a wireless radio-modem (GPRS/EDGE, UMTS), depending on the type of transport chosen (N). A variable set of I/O interfaces (serial, analogical, digital). The M2M Box The Asset If the device doesn t have an intelligent networking connection, it will still be possible to monitor and control most of its functionalities through a series of electric (analogical / digital) connections. S N This kind of enablement is today the only real option when dealing with the huge population of electronic devices that were not designed to be ready for M2M, and the offer on the marketplace of external M2M boxes is wide and differentiated. Figure 4 Retrofitting a generic device by connecting it to an external M2M Box, where S stands for software and N for networking Retrofitting is today the only real option when dealing with the huge installed base of existing devices. But when a business case has been proved, and a company is in the need to set up a full scale remote monitoring and management architecture, this option quickly becomes obsolete and a new more efficient type of M2M enabling solution needs to be put in place. That s where the BITXml protocol can be a great ally. Embedding a BITXml driver into a generic device Before getting into the details of this section, we believe it can be useful to try and figure out what might be the view of OEMs and embedded modules manufacturers and their concerns when considering the idea of making their products M2M enabled. In general, given all the hype around M2M, one could be led to conclude that enabling a generic device to M2M can certainly have a positive impact on any product s commercial appeal, but there are a few concerns: It is virtually impossible to predict the architecture of any complex system in which the generic device will be placed, and the network connection that will better suit the need of the end-user. This means that with a few exceptions - the product should be conceived in order to be as network independent as possible. 9

12 The marginal cost of the enablement process should be kept as low as possible. A fair translation of this can be: avoid massive product design changes and possibly limit or avoid additional hardware components. Once a product is M2M enabled, it should be possible to reach it and monitor its functionalities through an open (public) communications protocol. Choosing an open protocol means that any developer will be able to build a product-compliant software application. This is extremely important if the OEM doesn t want its customers to be forced to use a single proprietary M2M software solution. Assuming these requirements are correct, we can move on and describe in more details the central purpose of this paper: the consequences of embedding a BITXml driver. Once we embed a BITXml driver inside a generic device, this is ready to receive BITXml commands (in place of the One of the most important consequences of embedding an open protocol interpreter (the BITXml driver) into a generic device is the fact that any application developer will then be able to write a software application that can monitor / manage that device from a distance. usual complex binary commands) and when appropriate upload a specific M2M application from a central server. If we can do this cost effectively, the device will be able to be reached depending on the requirements via a wired or wireless connection. The advantages of this solution are three fold, as the new device is now: The network N The Asset S Network and architecture independent Figure 5 Embedding a BITXml compliant software driver (S) into a generic device. Able to talk a public and more expressive xml language Most important, M2M solution independent The BITXml driver: a closer look Even if we ve succeeded in taking you this far, there will still be plenty of questions that need an answer, such as: does this driver need a dedicated microchip?, what kind of operating systems is it compatible with?, do I have to pay a license fee in order to use the BITXml protocol specifications?, and many others of the like. So let s take a closer look at the concept of embedding a BITXml driver. By doing so we should be able to answer most of these questions. The vast majority of modern equipments in both the industrial and consumer markets are nowadays equipped with a good deal of local computational power. This means that their electronic boards Modern equipments comes with a considerable amount of computational power on-board, but this is almost entirely focused on executing local routines and controls. have been designed in order to include a microcontroller, responsible for the supervision of a pretty large number of tasks, which vary according to the specific type of device. For example, a modern HVAC unit s micro-controller will be able to supervise almost any function and state of the unit, such as fan speed, pump pressure, temperature and humidity sensors readings and 10

13 so on. Despite these relative large computational capabilities, such a micro-controller is almost entirely dedicated to the execution of local routines and controls, contemplating the idea of machine-to-machine communications only through a series of low-level commands exchanged through its serial port, with little or no consideration of what is going to be needed outside that equipment in order to make it part of a central monitoring architecture. The good news is that opening up that device to the world of machine-to-machine communications is just a few steps ahead. A generic microcontroller Let s try to describe a generic micro-controller here. No matter what type of processor, its memory, its computational power, no matter what type of operating system or the language used to write its firmware, we can assume such a generic microcontroller will look as in Figure 6. Optional M2M application Once the BITXml driver is in place, it will be extremely easy to upload a specific M2M application at a later stage. BITXml driver MC-specific firmware Operating System A BITXml driver can easily be embedded into any kind of microcontroller and make it M2M ready. Figure 6 A generic microcontroller In essence, a BITXml driver is a library containing a defined set of APIs (Application Programming Interface). The function of these APIs is to completely hide the XML schemas of the BITXml protocol and the complexity usually found in accessing the hardware resources of each give device (serial ports, I/Os ). Once the BITXml driver is on-board, writing a BITXml compliant embedded application that will perform a specific set of tasks and exchange data with an M2M middleware server-side is a much simpler job. BITXml drivers are available in the form of free code for all the major O.S. for embedded use on If the specific hosting platform supports it, the M2M application (the top layer in figure 6) can easily be uploaded Over the Air when (and only when) required. The whole process of M2M enabling is in this few, simple concepts. 11

14 A few introductory notes on the BITXml protocol main features BITXml is a public (open), XML-based M2M communications protocol and relies on the contributions of the community of developers, OEM and system integrators supporting it. BITXml defines the tools (messages, values) and the communication reference architecture for M2M interactions between the 3 main elements of an M2M infrastructure: The Central Master Unit (usually a middleware) The Local (external / on board) BITXml compliant application The distributed devices Controller BiTXml Gateway/Application Port-A... Physical/ logical connection Device 1... Internet/Intranet BiTXml Events, Histories, System messages BiTXml Commands/ Replies Master Unit (Middleware, custom application) In more details, BITXml provides direct support for : 1 any custom BiTXml-based application that can be installed either: on board of the device to be managed (embedding) or on board of the controller module (retrofitting) for other sub-devices 2 a well-defined process architecture: the gateway manager (again this can either be on the final device itself or on the controller ). 12

15 The BITXml protocol allow the definition of a series of gateway subprocesses: history collection local conditions monitoring and event propagation reconfiguration checks on-board command server Each of these subprocesses is server-side (master unit ) programmable and activated at initializationtime. Other important features supported by BITXml are: Device monitoring and actuation can be performed by accessing ports, which may be physical (GPIOs, RS232,...) or logical (User port, net socket,...) Easy extensibility (according to the inputs of the community of users/supporters) of gateway subprocesses, port types, ports operations As far as communication is concerned, BITXml supports two different types of interactions and network transport with the Master Unit (currently IP-based, mainly HTTP/POST and TCP/IP sockets, but not limited to them): 1 Asynchronous 2 Synchronous BITXml defines two different communication models: 1 Detached. Detached gateways/applications support only asynchronous connections, driven by them alone, and model autonomous devices. Detached model supports history collection, local conditions/events monitoring and the reconfiguration checker. 2 Connected. Connected gateways/applications support (optionally) all the detached model communication features, plus, as a mandatory feature, an on-board BiTXml commands server; used to model a device which requires the possibility of a direct command connection (real time access). As a final important remark, BITXml is totally independent from the chosen physical/transport connectivity (wired or wireless): another contribution in terms of flexibility. 13

16 Conclusions The decision to embed a BITXml driver can have significant strategic advantages: For one, because it makes any generic asset M2M enabled and ready to be connected to a central application at virtually no additional costs. Second, OEMs, chip and wireless modules manufacturers and end-users will not be forced to choose a specific M2M software paradigm when it comes to building the remote control server side application: any system integrator / application developer will be able to write such application based on the BITXml protocol specifications. Third, adhering to a public protocol can have a huge impact in the reduction of integration costs and complexities of a remote control project, especially when the monitoring infrastructure will have to deal with a complex architecture, involving heterogeneous components. In a world where everything is going to be connected this feature will rapidly become a must in many industries. Frequently Asked Questions If you haven t found an answer to all your questions in the previous pages, here is an additional list. 1 Which kind of microcontrollers can host a BITXml driver? There are many different CPU architectures used in embedded designs such as ARM, MIPS, Coldfire/68k, PowerPC, X86, PIC, 8051, Atmel AVR, Renesas H8, SH, V850, FR-V, M32R etc. This in contrast to the desktop computer market, which is currently limited to just a few competing architectures.. A BITXml driver can be written and adapted to virtually any type of microcontroller / operating system / programming language combination. Software is flexible by definition, whereas hardware isn t, so why should hardware specifications vary according to software requirements? 2 Do I have to pay a license for the use of the BITXml protocol specifications? No, BITXml was born as an open and public project. Downloading the BITXml protocol specifications and using them for the development of BITXml compliant products is subject to certain conditions of use (such as the need to mention the BITXml name), but it s free of charge. A full pipeline of open-source libraries for all the major hardware / operating systems in the world of embedded systems is already scheduled. For more information, check the website. 3 Does the BITXml driver need to be written according to a specific language? No, a BITXml driver can be written in any language (C, C++, Java,.NET, Windows CE ). 4 Who can write my BITXml driver? If you don t have in-house the competences needed to write a BITXml driver dedicated to your specific microcontroller design, you can ask your usual chip or electronic board supplier to do it for you, or you can have a firmware / embedded systems engineer to do it. Before you consider writing a BITXml driver from scratch, check the website: a free version of the BITXml driver that meets your requirements might already be there for you to download. 14

17 5 What are the additional costs I will be sustaining if I embed a BITXml driver in my product design? If your microcontroller is already fit for the hosting of an additional BITXml driver on top of its current operating system and firmware, the only expenses (if any) that you will have to cover are those related to the development of your own specific BITXml driver. If the current design of your product doesn t include a microcontroller (many fan coils do not have any intelligence at all, for instance), then your costs will be increased in reason of the additional microchip containing the BITXml driver. 6 Is it mandatory to embed the BITXml driver into the main microcontroller of any generic device, or is it possible to consider other options? In principle, you can embed a BITXml driver into any microchip. For instance, if the device is designed to incorporate a Bluetooth, Wi-fi (802.11b/g) or Zigbee module, then embedding the BITXml driver directly into the wireless module could be a wise option. With just one move you could solve at once two issues: making the device compatible with an open m2m communications protocol and avoid a direct wired connection as the only way to access your device. A BITXml driver could also be embedded into last generation wireless sensors, thus ensuring that a complex WSN (Wireless Sensors Network) can easily be integrated and monitored from a central server application. 7 What is the weight in kilobytes of the BITXml driver? There are a few variables affecting the BITXml driver s dimension, such as the type of microprocessor or the programming language and compilers used. However, we can say that on average the BITXml driver s weight can range from 50 to 100 kilobytes. 15

18 Via Mecenate 76/ Milano - Italy Phone Fax