George West conducted interviews of industry leaders. These were published in the WTRS Newsletter on a regular basis.
| Roland Acra (CEO) and David Culler (CTO) of Arch Rock George: What differentiates Arch Rock‘s products from others being marketed today? Roland: Data captured from the sensor gets conveyed somewhere in a repository that you can communicate with – it could be a database on the PC. So now the data is living here. Other folks are waking up to the fact that, gee, querying it using web services, with a structured database underneath it, is limited by itself. What we want to do in addition with our product is to make calls that activate an operation. It’s not just the database that I accumulated and that I can now query saying “give me the last five samples”. It’s: “please go now and change your sampling on the node”, “please go and average the last ten readings you have on the node and give me only the summary”, or “please go and let me know every time an event showed up.” So it’s not just the data that floated out of the sensors. It’s that anything you could do to the node in firmware is now doable remotely through the web services framework. Why do I care? Because I don’t want to have to be a firmware engineer to decide that the way that I was reading the data before is not exactly how I want it. I want to be able to try this, try that, change it, average it, repeat it. And either because I am the system or network person who is making all this work, or even the data guy who wanted to change the way the data is captured, I can easily access and control the network. David: In this first product, we put Gateway functionality and the higher level data storage services commissioning in the same box. Architecturally those products really have a Gateway, not a mote masquerading as a Gateway. Others have taken the approach of putting a web service interface to a database, which has existed in the TinyOS world since 2003 or 2004. What we have is a web service interface on a service that’s actually running. That is not fully exposed in this product because, in our effort to say “you don’t have to program the node”, we haven’t done that. But what we can do is, where you have a temperature reading, in a few characters I say temperature parameter, and all of a sudden ‘get temperature’ is a web service. One way we sometimes put this is “web services is the skin on the meat.” The meat is the underlying implementation, the IP integration is part of that meat, the embedded protocols are another slice of that, as well as the service layer on the node itself. Ultimately when people say, “Great, I love it. But I want to do something different there”, they still will have the ability to write services. George: If you speculate about a use case, this is the kind of service that is of value to somebody that is involved in process control or process engineering of some kind. Maybe there is a point where, before you have your performance bounds set and you want a lot of information, since you are kind of doing research and you don’t really know what is significant and what’s not significant. At the point where you understand the process a little better, you understand what knobs really to turn, then you go back in and say “ok, I don’t need a lot of this data. I either integrate it or aggregate it.” Roland: But it could also be imagined, for example, that you might want, in near real time, based on readings that came in, to go through a piece of software that has lots of sophisticated decision analysis in it, and trigger something as a result of that. It’s almost impossible to do this by going directly through firmware, whereas with our product you have the ability to combine logic, sampling, readings, etc. The ability to go in and say: now that this door has opened, I want you, Mr. Network, to do two things: buzz here, and turn on the light there. You could also have the network send you an instant message on your cell phone, ring the supervisor because the door just opened. For that to get done well, we need the web services integration because in real time you can send commands and get things back from it. This is different from simply viewing the data from different angles using web services, after the data has been dumped into the database. This gives you a lot more in the way of doing the kinds of things that matter at the application layer. It’s even more interesting if your decision system or your business problem extends wider than sensors. What if it’s sensors and RFID, and only the confluence of the two gives me the “Aha”. Ah, the RFID reader said this is box number 17 from the manufacturer and the sensors told me that it got shaken badly and dropped on the floor five times before it came. Now these two together make me do something different. It may trigger a replacement order, because I know this lot is most likely damaged so I go back and order the next thing to reduce my lead time. If you don’t have the instrumentation that services the whole operation, you pass on the ability to do these match-ups between several sources of data, of which maybe sensors are only one. These are the areas where we provide value: sensors with RFID, or sensors with location, or all three with some enterprise-derived data. David: The network as a whole becomes a first class citizen of the Internet. In addition, if you choose, the nodes themselves are accessible. Which means HP OpenView or my favorite IT management tool now can be used to control these nodes. We can now see this device as a member of the network rather than a network that has constituents. You won’t see that capability elsewhere. We can talk about web services applying to the whole, the ensemble, because sometimes that’s the right concept. We can talk about web services on the individual node. And of course that means you have to do name translation. I don’t have to invent a new way to do name translation. I need to do configuration and look up, I want to dynamically configure my host. Why invent? Use DNS and DHCP. Security? Use SSL, IPSEC. We don’t have to go invent a new set of answers, we can use the set of answers that are there. We are happy about SP100 because they very nicely laid out different classes and called for proposals, and in 2008, maybe, a standard will emerge. My guess is with the internal 6LoWPAN and so forth we’ll see that maybe we don’t have to argue about all those pieces, maybe we can bring in some of the IP stuff. We spent 25 years developing it, let’s use it. George: We have a comment we make internally to ourselves sometimes: we have enough standards already. So you can operate with your tool at any level of abstraction, really. You can even start making networks of these networks. Roland: And bring the toolkit that you use for your other IP devices. Today it has largely an operational benefit. There is transparency. I can trace through and find how many hops there were, how much delay there was. So this is all gravy from an operations standpoint. We have a faith that, in addition, the more tightly integrated you are at the IP layer and the web layer, the more you can do in the future. I might not know today, but I’ll be on that train which has a higher probability of running into more killer apps. George: Right. You don’t have to define the killer app. Some customer someplace will define the killer app. That’s Bill Joy’s statement: innovation always occurs someplace else. Roland: And sometimes you have to plant the seeds way in advance. The IP network and the routers, and so forth, had been there for decades before finally the guys at CERN in Geneva invented the world wide web and Netscape brought out its browser. And now all the information is indexed and universally accessible. Till then we were just doing email and file transfers. George: This answers a question. There is a gap between the device manufacturers and the statement that if you just make everything IP, you don’t really need to worry about it, and it just becomes ubiquitous. Roland: In some cases the app at the end of this IP node creates the womb for a new application. If we think about SMS, that was a new application that did not take hold until the cell phone caught up with the rest of the infrastructure. Sometimes it becomes a business in and of itself to make IP work in certain circumstances. It’s a little bit like making IP work for all the behind–the-firewall devices in our homes. Every LinkSys, D-Link, cable or DSL box we have turns private addresses into public addresses, puts in a firewall, and sometimes it turns five printers into one IP address accessible through the DSL connection. IP phones, well, it was one thing to say: “Just make them IP phones”. It was another to address the quality of service which forced people to do a lot of sophisticated queuing on LAN switches and routers to service the voice traffic ahead of the file transfer. We shouldn’t be daunted just because it’s hard, because the benefits always end up outweighing the difficulty of making it work. Sometimes making it work, in and of itself, is a business because people will pay a premium for it. But more strategically, it’s worth it because then it becomes a very fertile terrain for new apps to spread. This is as opposed to wireless cable replacement. George: There is value there. Roland: Absolutely. But that’s replacement value – for better convenience, lower labor costs, maybe more reach into places where wires were prohibitive. But as far as totally transforming the way things are done, as far as a paradigm change, that’s likely to be wireless plus something else, not just replacement of a wire. That is the value of this open top of the technology stack being available to every programmer on earth, to say to them “Here, these are my self-describing services. Have at it.” They are more likely to find the killer app that I never thought of because either they are smarter or they know their business better than I do. Who is going to be better at oil and gas than the oil and gas guy? Who is going to be better at logistics than DHL or their peers? We want this to be an open platform, for them to be able to innovate without being RF experts. George: This is kind of the key. What are the services available because you are using TinyOS? It is looking like the use of TinyOS ends up being a differentiator in terms of speed to market and the flexibility of the applications that you can create. David: There is TinyOS and embedded services. The embedded services are certainly built on top of TinyOS. Let me try the TinyOS part first. It was designed as a tool for implementing protocols. ZigBee didn’t exist, 6LoWPAN didn’t exist. It was clear that we were going to experiment with many different protocols. That meant managing a bunch of things happening. You have to juggle the management of streams of data going back and forth between sensors with a teeny tiny memory footprint. That’s the nature of these devices. That concurrency is tough. And if you look at many network stacks, ZigBee stacks and so forth, they attempted to do that without having an execution model. And so you end up with a library that you have to keep calling this tick function that doesn’t do anything; but if you don’t call it often enough, everything stops inside the network. Well, you really wanted to give it a thread, but you didn’t have threads. An apparatus for doing that is concurrency on a small footprint. The other issue was that we didn’t know exactly where the barriers were. We did time sharing, multitasking, in 1967. We know where those barriers are, but here it’s not so clear. So we decided to make defining abstractions – creating modules that you piece together and think hard about how you put them together up front. When you have thousands of these nodes out there in the world where you can’t touch them, it’s nice to do the thinking up front, rather than trying to think afterwards that if we have these conditions or those, what needs to happen to make it more robust. In TinyOS 2 we tackled both of those more carefully but we also said that there is a lot of diversity in platforms. So I need the combination of supporting a wide variety and I need to be able to optimize for any particular platform. Those were the things that TinyOS was designed to do. Now, in the purely academic world, its hard to do that last 10% of deep engineering, so part of what this team has spent a year doing is the industrial quality version of that. We got to take all of those good design concepts. That underlying TinyOS fabric gave us the tools for implementing really good networking protocols. Now if you want to bring IP in, we are not starting from scratch. The service layer is built on that substrate. But in some sense it’s a distinct thing of its own in that it says what I need to put on the network is a set of primitives – not a set of solutions – which I can then compose to build my application. Once I have put them there, I can actually synthesize a lot of the rest of the plumbing so that I can start to put them together. So if we look at the set of services that we provide, even down to quite low level things, what happens is I can add attributes to the node. I can set them, I can get them. Now I can generate the rest of the apparatus from that. This was a lesson learned through a series of large scale deployments when you don’t know exactly what it’s going to do until you actually put it out there. And once you put it out there, you can’t afford to go back and start tweaking it. What you want to put out there is really an engine, a set of services. This then became a tool for doing it. So, the service layer is implemented in TinyOS, but you won’t find it anywhere in TinyOS.net. We are the only ones who offer that service layer capability. It allows you to build the server from the description of what goes on in the node. It will take a while before people understand all of that necessarily. It’s pretty different from “Do I use the IAR compiler or not?” Roland: I guess it’s fair to say that our product’s hardware abstraction characteristics give us an advantage when in a six month period six different customers come in and say “I want a different chip”. One guy wants Freescale, the other guy wants TI, the third guy wants Jennic, and so on. So we say, let’s test our portability thesis: is it real? Have we really abstracted the hardware? So we turned around and released these abstractions on a monthly interval. If we had to make adjustments based on the chip – this is a big endian, this is a little endian – it would force us to rewrite everything. The more you want to serve variety and flexibility, which is essential in a nascent market, the better our solution serves the market. About Arch Rock: Roland Acra President and CEO Roland Acra joined Arch Rock as President and CEO in December 2005. Prior to Arch Rock, he was President and CEO at Procket Networks, a high-end Core Internet Router manufacturer, which he successfully led to an acquisition by Cisco Systems in 2004. Prior to that, Roland held several senior management positions at Cisco Systems from 1991 to 2003, including Senior Vice President and Chief Technology Officer, Group Vice President and General Manager of the Public Carrier IP Group, General Manager of the Remote Access Business Unit and Technical Director of Cisco in EMEA. Prior to Cisco, Roland held engineering development and technical leadership positions, at Bridge Communications and 3Com Corporation from 1986 to 1988 and at Interphase Corporation from 1989 to 1991. Roland holds Diplome d’Ingenieur degrees from Ecole Polytechnique and from Ecole Nationale Superieure des Telecommunications (Paris, France) and a Master of Science degree in Statistics from Texas A&M University. David E. Culler Co-Founder and CTO Dr. Culler comes to Arch Rock from the faculty of the University of California, Berkeley, where he has served as Professor of Computer Science since 1989. He was the Principal Investigator of the Defense Advanced Research Project Agency’s Network Embedded Systems Technology project (DARPA NEST) that created the open platform for wireless sensor networks based on TinyOS, and was the founding Director of Intel Research, Berkeley. He is a member of the National Academy of Engineering, an ACM Fellow, an IEEE Fellow and was selected in Scientific American’s ‘Top 50 Researchers’ and in Technology Review’s ’10 Technologies that Will Change the World’. He was awarded the NSF Presidential Faculty fellowship and NSF Presidential Young Investigator award. He has done seminal work on networks of small, embedded wireless devices, planetary-scale internet services, parallel computer architecture, parallel programming languages, and high performance communication, and specifically includes TinyOS, PlanetLab, Networks of Workstations (NOW), and Active Messages. He has served on Technical Advisory Boards for several companies, including Inktomi and ExpertCity (now CITRIX on-line). David received his B.A. from U.C. Berkeley in 1980, and M.S. and Ph.D. from MIT in 1985 and 1989. West Technology Research Solutions, LLC © 2007 All Rights Reserved |