Edge Connectivity in ThingWorx™ Extending the ThingWorx Platform Out To the Physical World
W HITEPAPER
A
MODERN APPROACH TO INTEGRATING REMOTE RESOURCES
INTO YOUR CONNECTED APPLICATIONS
One of the hallmarks of ThingWorx is its ability to integrate the physical world into business processes. These processes increasingly require information from and interaction with people, enterprise software systems, and remote devices. Unfortunately, not all physical systems are created equally and there is no universal answer to integrating those remote systems into your business processes. Fortunately, ThingWorx was designed with a deep understanding of device connectivity and the myriad of existing connectivity models as well as with a modern AlwaysOn™ model that addresses many of the problems with existing solutions. This whitepaper discusses the varied mechanisms available for seamlessly integrating both legacy and newly designed edge devices into the ThingWorx platform.
Edge Connectivity in ThingWorx
T ABLE O F C ONTENTS 1
AN IMPERFECT WORLD ......................................................................................................................... 3
2
A TAXONOMY OF EDGE CONNECTIVITY ................................................................................................. 3
Direct Connect ......................................................................................................................................................... 3 AlwaysOn™ .............................................................................................................................................................. 4 AlwaysOn™ Embedded ............................................................................................................................................ 5 AlwaysOn™ Tethered ............................................................................................................................................... 5 AlwaysOn™ Network Gateway ................................................................................................................................ 6 Device Cloud/Internet Gateway............................................................................................................................... 6 3
SUMMARY ............................................................................................................................................ 7
www.thingworx.com
Edge Connectivity in ThingWorx
1
A N I MPERFECT W ORLD In a perfect world, where bandwidth is free and unlimited, batteries last forever, all devices use the most modern of communications technology, and everyone on the Internet is friendly and law abiding, connectivity with edge devices is simple. Bi-directional REST based interactions enable interactive communications between an edge device and the ThingWorx server and visa-versa. Unfortunately, unless everything is line-powered and deployed within your own private network, the world is far from perfect. On wired networks there are firewalls and other necessary IT security infrastructure. On wireless networks there are issues with the cost of bandwidth, unpredictable IP addresses, and battery life. And in all cases there is the need for encryption, authentication, authorization and auditing to keep information away from prying eyes. Over the years many technologies have been developed and deployed to address the myriad of different scenarios and requirements for remote device connectivity and it is simply not realistic to expect companies to start from scratch when developing new connected applications. Therefore, the ThingWorx platform must not only support legacy systems, it must embrace them, attempting to bring them into as near a perfect world as possible. That is the goal of the ThingWorx approach to edge connectivity: abstract away any imperfections of the existing connectivity model so that applications built with ThingWorx can work with as secure and perfect a world as possible.
2
A T AXONOMY
OF
E DGE C ONNECTIVITY
Edge connectivity takes multiple forms and people have been classifying these forms in many ways. The most often used breakdown is wired vs. wireless. However, with the rapid advances in wireless capacity and bandwidth, the technical distinction between these is less important. What is important is the ongoing operating costs that wireless brings with it. Another cost that is often overlooked is energy costs to operate a specific transport. In battery powered systems this can be a very significant expense in terms of downtime and battery replacement costs. ThingWorx takes these factors into account as it looks at the connectivity taxonomy in a slightly different fashion. The ThingWorx platform has been architected to easily support the following modes of interaction with edge devices and sensors. Direct Connect There are certain deployments where the ThingWorx server, either standalone or in a federated model, and an edge device can interact directly through mutual HTTPS REST based interfaces. Consider a manufacturing facility where all the equipment is on the same network. Each piece of intelligent equipment may have its own controller and Human Machine Interface (HMI). The system used for the HMI typically has enough resources to also expose its data to the network via REST based web services or some existing interface such as OPC or ODBC. In
www.thingworx.com
E Edge Connecttivity in Thing gWorx
this scenario it is quite possible p for a ThingWorx T se erver and thiss edge device e to communiccate directly in a secure fashion without th he need for an ny additional protocols to overcome o anyy network inffrastructure hurdles such as a firewalls an nd proxy serve ers. An exam mple of such a deploymentt is shown in the figure below.
The downside to a directt connect mod del is that it assumes a that the ThingWo orx platform and a the edge de evices are on the same nettwork or at le east directly contactable. Of O course thiss is not always the case and ThingWorx has h developed d other conne ectivity mecha anisms to sup pport alternative scenarios. s AlwaysOn™ ™ The ThingW Worx AlwaysO On technologyy is lightweigh ht, scalable, and secure. Itt incorporatess presence an nd real-time connectivity, c s supports fullyy bidirectional communications (both pu ush and pull), and can be utiilized on both h wired and wireless w netwo orks without the t need for bandwidth wasting w consttant polling. The beauty of o AlwaysOn iss that it abstrracts away the network com mplexities succh as firewallss, NATs, and needing to kn now IP addre esses while still providing fo or a highly seccure and scalable interaction between the t server and d the edge de evice. Establishing g ‘AlwaysOn’ connectivity c f from the devicce to the servver is also verry IT friendly since it does not require any open o incoming g ports or cha anges to the network n security infrastruccture. This connecctivity model is also quite friendly f to wirreless operato ors as it remo oves the need d for the infrastru ucture require ed for assigning static IP addresses a so that t devices can c always be e identified by y the applicattions that inte eract with the em. The unde erlying transp port for AlwayysOn is standardss based and can c be either XMPP or Web bSockets. When using g AlwaysOn, one o also gets the benefits of o the ThingW Worx Edge MicroServer (EM MS). The EMS is the key to prroviding transsparent access to ThingWo orx server pro ovided Web Services fro om the edge as a well as pro oviding transp parent access to edge base ed Web Servicces from the Th hignWorx servver. The EMS S also plays a pivotal role in integrating with both leg gacy equipment and newly de eployed system ms by exposing propertiess and servicess provided by edge applicationss to the serve er as RESTful Web Servicess. Finally, the EMS can alsso provide additional edge e intelligen nce though a built in scriptting environm ment. This edge intelligencce can be used to aggregate an nd preprocesss data, perform m data comprression, proviide remote desktop and d file transferr capabilities and a perform other o function ns needed to optimize communications with the e server. There are many m ways to deploy the ThingWorx T Alw waysOn techn nology. Each of these optiions are covered d in the follow wing sections of this docum ment.
ww ww.thingworxx.com
E Edge Connecttivity in Thing gWorx
AlwaysOn™ ™ Embedded For new pro oducts under developmentt or products in the field th hat can be up pdated, embed dding the EMS dirrectly into the e product’s software or firm mware is a hig ghly desirable e solution.
The benefitts of such a so olution are many including g a tight integration of the product into the ThingWorx platform, no additional de eployment ste eps since the EMS E is built riight into the product, and the ability to t remotely update not only the EMS, but b the device e’s software as well. AlwaysOn™ ™ Tethered In many rem mote service scenarios, the e immediate value v of ThingWorx is with h the installed d base, not with w new products under de evelopment. The cost savvings and incre eased uptime e of the equipment create bo oth a compelliing business case c and uniq que differentia ator for an equipment provider. Ho owever, a lot of o legacy equipment was not n designed with connectiivity in mind and d simply may not have the networking hardware, h ressources, or up pgradeability to t support the e ThingWorx EMS. E ThingW Worx does nott ignore these e legacy syste ems, and in fa act one of the fundamental f t tenets of the ThingWorx platform p is to embrace lega acy. In these e scenarios, the t ThingWorrx EMS can be e deployed in what is called d “Tethered” mode.
ww ww.thingworxx.com
E Edge Connecttivity in Thing gWorx
In Tethered d mode, the ThingWorx T EM MS is deployed d on a very lo ow cost “blackk box” such as a a Serial<->Etthernet gatew way and conne ects to the de evice via some existing dia agnostic interfface. The scriptin ng environment of the EMS S can then be e used to communicate with the legacy device via whatever w prottocol it supports over that interface whe ether that is a standard protocol succh as Modbuss or some pro oprietary custo om protocol. In either casse, once that connection is made, the device is tran nsformed into o a fully functional, interacttive “Thing” in n the ThingWorx universe. AlwaysOn™ ™ Network Ga ateway It is quite common for an equipment vendor to have many deviices deployed d at a single customer site. Often, th hese devices reside r on the customer’s network and may m have som me master serv ver that provid des a commo on user interfa ace for interaccting with the e product. Th hat centralized controller ma ay also have information orr aggregated data regardin ng the device es that is not necessarily n avvailable at the e individual de evice. In such a scenario, ThingWorx supports de eploying the ThingWorx T EM MS as a Netwo ork Gateway.
In this deployment scena ario, the Thin ngWorx EMS iss deployed on n the local server and actss as a channel of connectivity c u to the Thin up ngWorx serve er. However, because of th he connectivitty model desig gned into the ThingWorx EMS, E each of the t remote de evices is reprresented separately, as its own un nique Thing within w the Thin ngWorx platfo orm. The bea auty of this architecture e is that the end e applications have no id dea, and do not n need to kn now, whetherr the device is co onnected through a networrk gateway, a tethered EMS, or has the EMS embedd ded into the pro oduct software e. Device Clou ud/Internet G Gateway One final de eployment sce enario for ThingWorx is co onnecting thro ough one of the t plethora of o “Device Cloud” solutions that seem to o be popping up every dayy. Cloud providers such as Cosm™/Pacchube™, Axed da™, iDigi™, and nPhase™ ™ are essentia ally pipes thatt connect rem mote device data streams to a centralized data d repositorry.
ww ww.thingworxx.com
E Edge Connecttivity in Thing gWorx
These pipess may use either wired or wireless w conn nectivity, but the t end result is the same. The data th hat is collected d is then mad de available via some proprietary APIs or o Web Servicces. In such a sccenario, the power p of the ThingWorx T exxtension mech hanism becom mes readily apparent. Integrating I on ne of these device clouds into ThingWo orx is a matter of creating the t appropriate e extension re esource that understands u the device cloud’s particula ar API and add ding it to your Th hingWorx dep ployment. Once deployed, the devices attached a to th he Device Cloud can be mod deled and insttantiated just like any othe er Thing in the e ThingWorx universe. In fact, in many casses life is even easier since e several such h extensions have h already been created d for the most po opular Device e Clouds.
3
S UMMA ARY The ThingW Worx platform is “The First Platform for the Connecte ed World”. In n order to live e up to that claim m it must provvide a secure e, cost effectivve way to con nnect with devvices of all sh hapes and sizes. With W built in ability a to supp port many diffferent connecctivity scenarios, the ThingWorx platform provvides the flexibility to hand dle both wireless and wired d networks in n direct conne ected, AlwayssOn, and occa asionally mod des. In additio on, with an easy e to use Ed dge Adapter exttensibility mod del, the Thing gWorx platforrm can be exttended to sup pport both standard an nd proprietaryy protocols an nd their assocciated installed d base of devvices.
Cosm, Pachube, P iDigi, Axeda, and d nPhase are Trademarks T o their respecctive companies. of
ww ww.thingworxx.com