Sunday, September 18, 2011

Embedded: A Fresh Look at Embedded Java


Defining the Embedded Space


“I use ‘the embedded space’ to refer to any device that includes a general-purpose processor and OS plus a software execution environment, but which would not be identified as a computer by a layperson.” 
Q: How would you define the embedded space?
A: I use “the embedded space” to refer to any device that includes a general-purpose processor and OS plus a software execution environment, but which would not be identified as a computer by a layperson. This encompasses everything from printers to refrigerators to cars to ATMs. To put this in perspective, automakers now claim that about 70% of the perceived value of a new car is in software and electronics. That is an astounding observation! Think about it--the wheels and tires and fins and interior materials are no longer what differentiate cars from their competitors. Car companies are increasingly focusing on electronics and software to enhance the value of what they produce. The rest of the car is pretty similar--all have four wheels, the internal combustion engine, maybe even electric motors now instead of gas. That part is very similar.
My job is to take a fresh look at how to support embedded developers and create an ecosystem in the embedded developer space so that Java is considered a possibility for implementing software on embedded devices. Currently, we have Java being deployed in a wide variety of embedded devices including eReaders, ATMs, routers, multifunction printers, VOIP corporate phones, POS systems, medical devices, industrial controllers, and smart meters. Even deli scales and parking meter systems.
Still, we're just scratching the surface when it comes to Java for embedded. We know there are many developers who, unfortunately, don't automatically think of using Java for their next embedded project. We want to change that since Java has many features valuable to embedded developers, including multicore support, security, multiplatform support, and networking. 
To create new projects, we want to create a VM and library set and some tools to entice the embedded developer to use Java for their next project. So that’s my mission.
Q: How are you trying to accomplish it?
A: It takes persistence. We have to make the case that Java is the right answer. We want to take away the artificial divisions within the Java platform because embedded devices are getting more capable and we might want, for example, to have Web servers and databases on them. There’s a lot more that users want these days, so we might want pieces from all parts of the Java platform and not just some subset that was built with mobile handsets in mind.

Recently we released the Oracle Java ME Embedded Client 1.0. This release is the first significant departure from how ME has been distributed in the past in that we are releasing binary runtimes for particular OS/processor architectures. Now, embedded developers can download, install, and begin creating Java programs on typical embedded hardware in minutes. We are very excited about this addition to our arsenal of tools and runtimes for embedded Java development.
The Rapidly Changing Embedded Space
Q: Give us a sense of how the embedded space is changing.
A: It’s undergoing rapid change. The code bases are expanding exponentially; the code is getting more complex with greater functionality and more multicore functionality. There is more connection to the Web and to OEM headquarters but, of course, bill of materials costs is still crucial.
“Now, embedded developers can download, install, and begin creating Java programs on typical embedded hardware in minutes.”
As I suggested earlier, hardware is no longer the interesting part now, not just with automotive, but with everything. We know how to make printers, stereos, cameras, TVs and DVDs, traffic signal controllers, planes, washing machines, and refrigerators--that is no longer the issue. Manufacturers are now competing with functionality that is created in software, so larger and more complex code bases are required. Traditional embedded code was simple, with maybe 200 lines of assembler language required to do some softening up of the hard edges of the hardware. Now they have to connect to the Internet and to headquarters for maintenance. They have to record information about the behavior of the device, so the manufacturer can support the system and monetize some of that information. So the code is getting more complex and more and more functions are being demanded, because that is how manufacturers differentiate their products. They are telling their embedded teams “We need six buttons because our competitor has only four” and (tongue-firmly-in-cheek) “A six-button washing machine must be better than a four-button washing machine.”
Multicore functionality is a big new thing coming to the embedded space--it’s never been there before and manufacturers have no idea how to deal with it. Embedded developers know little about multithreaded applications. Multicore is brand new to them, so they lack the tools and language support to deal with it. Some of the early C libraries that are still out there are not even multithread safe and can’t be used in a multithreaded environment. So a big change will be coming in embedded software development when multicore hits. Java, of course, has had excellent multicore support from the beginning and we will bring that support to embedded developers.
Car manufacturers want to reduce the number of processors on their machines. To do that, the code base on a particular processor will have to be more complex, because it will have to do what six processors were doing with simple code. Now all that code is on one big processor connected to the network in the car. So, all these trends in the embedded systems lead to the demand for a software development environment that is more advanced and of a higher abstraction. That’s where we are today.
Currently, most of these devices conduct a lot of internal measuring of what’s happening in the device to keep it running. But those measurements are just used internally in the control algorithm to keep the device functioning. Let’s take a refrigerator, which has a lot of mechanical functionality and a processor in it. It has to regulate the temperature in a couple of compartments--it currently does that electromechanically, but there is a move to digital control of the cooling system. It measures the temperature of the compartments, and both when and how many times the door opens. It measures the internal pressure of the Freon in the compressor and the compressor temperature when it is operating and not operating. All this goes into managing the system and the code logic.
It periodically makes decisions based on all this information and then returns to measurement mode. If all that data were collected and stored and moved to large databases on the manufacturer’s IT side, it would be valuable in several ways. There is value for the manufacturer in statistically analyzing how their devices behave in the real world, how they break, and what the repair costs are, as well as in identifying trends in order to refine the design to reduce the failure rate in deployed devices.
This information can be monetized for the customer as well. The easiest example is automotive. If all the information from all the processors on your car was recorded in a local database and then uploaded to the manufacturer, when you got in range of your home Wi-Fi, the manufacturer could provide you with a detailed report about your automobile. The report could tell you how the oil level is changing and provide information about other issues.
The manufacturer could send you e-mail when you need to get an oil change. If the car had the appropriate sensors internally, the manufacturer could describe the condition of the oil. Does it really need to be changed or can you extend the life of the oil?
If you drive freeways, your oil will stay better longer than if you engage in city driving. That is an artifact of how internal combustion engines behave. So if in one 3-month period you are doing a lot of freeway driving, maybe you don’t need your oil changed for four or five months. If you do a lot of starting and stopping, or it’s dusty and the dust degrades your oil, it might be better to change it in two months. With appropriate sensors, monitoring, and analysis, you can monetize that information by sending customized e-mails informing customers about what they need to do, as opposed to having them follow standardized intervals that might or might not apply precisely to a particular car. All of this fits well into the state of the world today, that is, we, as a society, have to optimize the consumption of fuels and energy. Larger, more complex, and intelligent software programs on our devices will allow us to use fuels and energy as miserly as possible while still having acceptable function and performance.
That might save oil--you might not change it as often, plus someone else is keeping track of it for you. There is a lot of value in collecting the operational data to send back to the OEMs for analysis and subsequent monetization.   
Java in the New Embedded Space
Q: How does Java fit into this?
A: I’ve been talking a lot about automotive but let’s generalize a bit now. You need a fairly complex software architecture to integrate these devices into the networked world. Doing that from scratch is pretty tough. Oracle can provide the client-side piece, the piece in the device, as well as the back-end servers and the middleware. That, combined with a very small amount of engineering from the device manufacturers, can enable manufacturers to collect operational data on the device, time stamp it, save it to the local database, and have that data be automatically synced with the back-end database and, thus, available for analysis and provision of new services for the device owner.
“We think Java is the right answer and the next step up in language abstraction. It makes it much easier to build large, complex software artifacts.”
Q: What is Oracle doing along these lines?
A: At Oracle, we have what is called the Oracle Berkeley Database or BDB. It’s an embedded database that comes with a thin client with anything you write for the BDB on the client, so whenever the system is in range and the thin client can get a connection to its mother database, it does so and replicates the data from the client to the mother database. Developers don’t have to think about that--they just install BDB and the thin client, all in one package.
As the control loop executes, it creates a lot of operational data that can be saved to an object in the BDB and reflected at the manufacturer’s headquarters. The BDB runs on Java as a Java program. One feature that differentiates us from the rest of the embedded space is that we have a designed Java VM for writing your app, plus the BDB and the client. That is a package that makes the collection and transfer of operational data pretty much a no-brainer for the embedded developer.
It’s really simple to make this happen. So why Java? And why Oracle for embedded developers? The middleware data-movement infrastructure already exists for the general-purpose world and we are pushing out little arms of this big world to allow it to run on these embedded clients.
Q: When will this happen?
A: We have some embedded Java products now, and we are talking to the BDB folks about packaging together with embedded Java to make it dead simple for developers to take advantage of the function. We have these pieces and we can create these things for customers today. It’s not yet a single product but the pieces are there. Embedded software developers are pushing the limits of their tools and their development capacities. We think Java is the right answer and the next step up in language abstraction. It makes it much easier to build large, complex software artifacts.
Call to Action for Developers
Q: Is there a call to action for developers here? Any appeals?
A: The call to developers is to download Oracle’s Embedded Java products, get one of the supported embedded hardware reference platforms, for example, the SheevaPlug, and write their first Java program.
See Also
Posted by at
Labels: , , ,
Location: Street 17, Monshaat Nasir, Qism Helwan, Cairo, Egypt

No comments :

Post a Comment

Subscribe to: Post Comments ( Atom )