Android in Automation

C

Thread Starter

Curt Wuollet

As I sit here, quietly contemplating my next direction, I lick a finger to test the wind direction, and there is a low approaching roar, a welcome change. It seems that 75% of new computing devices sold run Android, 138 million or so in the past 3 months. Apple is running second, with MS a bit player. It seems we might be seeing a trend towards a new "duopoly", ARM and Android. But. duopoly is not the right word because the new wave is OPEN. On my desk is a perfectly functional $35 computer that would make a great HMI, and I'm toying with the idea of buying the seasons hottest 7" tablet, the Nexus 7 for $200 and setting up to write Java for Android. Android itself is no challenge, I have been a Linux person for a decade or more. Java will be the struggle as I've never been a big believer in OO and it seems an odd choice for embedded work, but I mean to catch and ride this wave. SO, My question, gentle reader, is when and how do you think this wave will impact automation? No doubt, many of you have become Android, and therefore Linux, users whether you have thought about it or not. Will the bastions of proprietary hold?

A timely discussion.

Regards
cww
 
D

David Ferguson

As the past 12 year discussion has proven over and over, and as i always forget, most of us on the cool bleeding edge are in the minority. We forget that but most department heads want no hassle and someone to hold harm if something doesn't work.

My son who is all about open environments, (Controls Engineer in an R and D dept), said it best, that we forget how spoiled we are to have Win 7 boxes that just work and no driver hunting etc.

I hate to disagree with you as I wish we lived in an open world, where everything was free and the community rushed to our aid at 3am when the machine crashed......but that isn't reality right now and we have multi million dollars at stake and therefor want a company that spent millions in developing the control system ie Rockwell, Emerson etc. and don't really care that that isn't cheap.

In most plants it is chump change, for instance, in my area is a billion dollar mine and to be steel mill being built, all of the controls are between 3 and 5 million or peanuts. And the real money is controlled by Mechanical vs Controls people, who don't have time nor care about that small a piece of the pie.

I think we will be having the same conversation again in 5 and even 10 years.......we will see, but I will bet a pay check on that one (still).

Dave Ferguson
Control Systems Engineer

Sent from my iPhone
 
C

Curt Wuollet

Hi Dave

Before, it was going to happen.
Now, it's happening:^)

I'm fairly sure the difference between even a ruggedized x86 PC and a sealable 25 watt multicore ARM machine is not lost on the automation manufacturers. But, I would have been truly disappointed had we not heard your perspective.

Regards
cww
 
Hello Curt,

you will know our http://pvbrowser.org which is a client / server framework for SCADA.

The client (pvbrowser) is a GUI software based on Qt and programmed with C++.

This client now runs on all operating systems on which Qt is available.
Besides Linux/Unix/Windows/OS-X this is now Android/Maemo/MeeGo/Symbian (mobile OS).

On Android you do not necessarily need to code in Java.
Qt and C++ are an alternative.
http://qt-project.org/wiki/Necessitas

In order to run our pvbrowser on Android you only had to recompile, add gesture support, optimize for different screen.

It runs very well on my Asus Google Nexus 7''
 
C

Curt Wuollet

That is true, after all Android is a stack on top of a Linux kernel so you can persuade other stuff to run. For that matter you can probably run Ubuntu on your Nexus 7 by now. But the Android Brand implies apps built with the Android SDK. Indeed that's one of the issues I'm seeking to discuss. Is Java a good fit for the parts of automation that now tend to be Windows and PC territory? Or for that matter, will people color outside the lines and mix in C and others? Could one do say, something like RSLogix in Java?

Regards
cww
 
T

Tallak Tveide

> people color outside the lines and mix in C and others? Could one do say, something like RSLogix in Java?

Inductive Automation does a Java HMI system, so that should be proven possible by now. ;-)
 
R

Robert Scott

Curt,

I have already used Android tablets as the user interface in a piece of custom portable factory test equipment. It is a device that uses an ultraviolet light source to measure the fluorescence of a doped oil film coating on sheet steel as a marker of the oil film thickness before the stamping operation. The custom hardware is all implemented in a small PIC which controls the strobing of the light source and the data collection and communicates over bluetooth to the Android tablet which forms the entire higher-level processing and user interface. I think it is a very cool interface. And not having to implement a user interface or data storage in the PIC board made the design of that board very simple.

Java is not problem. It is a solution. The free Eclipse IDE and SDK from Google is really slick (provided you run with lots of memory in your desktop computer). The Java interpreter is quite optimized and is not a hindrance in most applications. I have another Android application that needed to do real-time FFTs and in that app I used the Native Development Kit (NDK), also available free from Google, which allows you to write C code subroutines that get compiled into native ARM. But I would not try to write the whole application in C. That gets very messy. And it is not necessary because most of the UI is not CPU bound. So I use the NDK only for the FFT analysis.

I predict a reasonably good future for Android devices in factory applications.

Robert Scott
Real-Time Specialties
Hopkins, MN
 
C

Curt Wuollet

This is the type of thing I needed to hear. The PC world is still headed in directions not helpful to automation. The mobile device world is beginning to look like a better fit from several standpoints. That is, a PC replacement device. eg raspberry pi or APC that uses the same technology might have several advantages and fewer drawbacks than the somewhat overgrown x86/Windows platform. And the recent secure boot and W8 changes will be something of a nightmare for automation people. Getting legacy apps to run on new PCs may not even be possible. It will certainly get interesting going forward.

Regards
cww
 
> This is the type of thing I needed to hear. The PC world is still headed in directions not helpful to automation.
> The mobile device world is beginning to look like a better fit from several standpoints. That is, a PC replacement
> device. eg raspberry pi or APC that uses the same technology might have several advantages and fewer drawbacks than the
> somewhat overgrown x86/Windows platform.

For "intelligent" machines it is not necessary to have a full blown PC with a host of applications.

Instead you want a flexible way to run your own software on the device and have a host of interfaces like USB/RS232/RS485... or direct digital and analog I/O on board.

And you need a Network connection either over RJ45 or WLAN.

A problem seems to be the life cycle of these devices. These seem to be much shorter than the life cycle of a machine.

You will probably use some Linux type OS on that device and
i would insist to be able to develop in C/C++ also.

The GUI should be something which is reusable either web interface or which i propagate a browser that is optimized for process visualization (our pvbrowser).

The application logic should run in the background (daemons) and should not have a GUI at it's own.
 
R
> ...You will probably use some Linux type OS on that device and
> i would insist to be able to develop in C/C++ also...

What is your reason for avoiding Java? Do you not consider it as solid as C/C++? Or do you have a large library of C/C++ code that you want to reuse? If that is the case then the NDK will compile C/C++.
 
I want to write source code only once.

The result should be usable from microcontroller up to high end systems.
C/C++ is available on more systems than is a Java VM.

The runtime behaviour of the software should be predictable, no garbage collection.

I prefer my own libraries in C++ because i have full control about them.
Currently i use Qt for GUI purpose because it's the only library that has really proven it is possible to write code only once and deploy everywhere.

Really i indirectly use Qt by means of our pvbrowser.
 
C
Comments interspersed

>> This is the type of thing I needed to hear. The PC world is still headed in directions not helpful to automation.
>> The mobile device world is beginning to look like a better fit from several standpoints. That is, a PC replacement
>> device. eg raspberry pi or APC that uses the same technology might have several advantages and fewer drawbacks than the
>> somewhat overgrown x86/Windows platform.

> For "intelligent" machines it is not necessary to have a full blown PC with a host of applications.

Not for the actual controller, but some OS services are convenient for HMI and programming machines.

> Instead you want a flexible way to run your own software on the device and have a host of interfaces like USB/RS232/RS485... or direct digital and analog I/O on board.

Yes, the PC world seems bent on getting rid of all the interfaces and connections to the world that suit automation. And on the software side eliminating the direct control of hardware. This is fine I suppose for surfing and running office suites, but requires all kinds of kludges and workarounds for automation.

> And you need a Network connection either over RJ45 or WLAN.

No problem there, drawing from the mobile world implies connectivity, generally multiple types.

> A problem seems to be the life cycle of these devices. These seem to be much shorter than the life cycle of a machine.

Yes and no. Driven by the insane pace of consumer demand for phones and tablets, yes, the life cycles are short. Stepping back though, I can obtain low cost SBCs that are off the shelf now and are completely open. In other words, I can buy the boards and I get the artwork and schematics and firmware and OS and everything else I need to have the boards built in house or by any good local contract house. Due the extremely high degree of integration, these boards are not very difficult to build and the issue becomes silicon availability. The devices are in high volume production, really high and are cheap. And some vendors will actually guarantee availability for years. Without getting really clever, it's practical to manage your desired lifetime by stocking the unique components. From that viewpoint, these are less complex than many past embedded designs that companies routinely managed for decades. Of course, a really good solution would be if some industry association would endorse the designs and get members to standardize on a few. With this buying power, one could negotiate availability and make many other good things happen. But that's like herding cats in automation. I'll put it this way, I could design one of these on the kitchen table and manage availability for a predictable cost. That gives me a lot of confidence.

I'll cite an example of what I am talking about:

https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-WIFI/
https://www.olimex.com/Products/OLinuXino/iMX233/

Standard disclaimers apply: I would be a bit leery of the A13.

Suitable platforms exist now, in quantity, at low cost, with multiple sources.

These are examples of tablet guts in industrial temp ranges and form factor. They run Android and Debian, etc. And I'll bet they would handle HMI, programming tools _and_ control. With appropriate I/O they would make a super plc. With little (Android) or no (Linux) licensing BS.

> You will probably use some Linux type OS on that device and i would insist to be able to develop in C/C++ also.

No problem any Android device _is_ running Linux.

> The GUI should be something which is reusable either web interface or which i propagate a browser
> that is optimized for process visualization (our pvbrowser).

This is being pursued with the utmost vigor by Google, everyone else and dog.

> The application logic should run in the background (daemons) and should not have a GUI at it's own.

Yes, Linux is very, very, good at that.

Regards
cww
 
>Yes, Linux is very, very, good at that.

We think similar.

But it seems you did not look deeply on our concept for GUI and HMI.
I think it is especially interesting for above devices.

You would only run the pvserver on the embedded device.
 
>A timely discussion.

"automation" at least in the context I know it, runs on devices fixed in place whether they be servers, controllers and the like.

The personal devices have merit as a user interface, or alarm notification. I was just at one of our sites a few days ago, & the operator was saying they are not 100% in front of the client PC's. We send alarm emails and notifications to hand helds, but we could also support a tablet device as a client. Never had the request to do that..yet.
 
I have really been wondering about QT and C++ lately because I've written a lot of code in C#.NET with windows forms and I feel like I'm slowly being abandoned for (in my opinion) an overly complex GUI system of WPF. I don't like where MS is headed and it seems that they are accelerating away from their loyal user base (Come on ... Ribbons in office ... ridiculous tile screens for windows 8 desktop, developing being pushed toward WinRT after shoving .NET down our throats for the last 10+ years!! Ugghhh..... ) MONO used to be a way to have cross platform support using (to some extent) windows forms, but that was never great to begin with and has stopped being developed by both the mono guys and also Microsoft (MS wants you to use the WPF for new apps).

With the move to android the widget set is all new, so it is yet another learning curve. If using QT could eliminate that learning curve I am all for it.

If I could write in C++ with QT as a widget set and (potentially) and application framework for boiler plate stuff like making TCP/IP connections that I can transparently port between systems this would be ideal. To port your app from a PC to android would be a great benefit.

The big problem I have with android devices is not technical it is the life cycle, the batteries (for a static HMI), and startup behavior, and lack of connectivity (depending on the device). IT sounds silly, but when you are used to an HMI that runs off of 24VDC, auto powers on with the system and loads your HMI and has two good ole RS-232 ports and a 100mbit Ethernet you get used to how solid everything is. If there were multiple manufacturers who had ARM based HMI in the 7-10" range that had all of this and ran android we would be in business. I also prefer a glass screen similar to the mobile devices, for some reason the plastic overlay resistive screens still prevail in the automation world and it drives me nuts that the durability is so bad.

KEJR
 
R
>I want to write source code only once.

>The result should be usable from microcontroller up to high end systems.

The goal of writing source code only once is rarely achievable in practice. It can be done for very well-defined generic data processing tasks, such as a Fast Fourier Transform, or a sorting routine. But a lot of source code is by its very nature dependent on the platform in which it runs. Look at the typical C/C++ application written for the Windows platform. Then ask yourself how much of that code would transfer over to a Linux machine. And I'm not talking about a Linux machine running some Windows emulator because then the compatibility is being provided not by the universality of C/C++ but by the emulator that makes the software think it is still running in Windows. Then look at a resource-constrained Microchip PIC18Fxxx series platform that can also be programmed in C. At the very least you are going to have to examine every line of the Windows application code to see if fits the PIC platform resources.

> The runtime behaviour of the software should be predictable, no garbage collection.

This of course depends on what aspects of a task you attempt to assign to the platform in question. Even the portable real-time data collection device I described earlier is naturally partitioned into the truly hard real-time jobs and those that are not so time-critical. We would never think of trying to control timing the strobing of the light source and the triggering of the A/D converter synchronized to this strobing in the Android device. For that we use a dedicated PIC (which is programmed in C). The PIC communicates with the Android tablet via a serial port to bluetooth module. This leaves the bulk of the code in the Android - handling things like calibration, the user interface, and data storage. There is no reason to worry about the impact of garbage collection for those tasks as they do not have hard real-time deadlines. The same considerations would have to be made in a Windows C/C++ implementation since real-time latency cannot be guaranteed there either. So don't blame Java for something that afflicts C/C++ applications too.

> I prefer my own libraries in C++ because i have full control about them. Currently i use Qt for GUI purpose
> because it's the only library that has really proven it is possible to write code only once and deploy everywhere.

Well, everywhere Qt runs. And that is certainly not everywhere.

Robert Scott
Real-Time Specialties
Hopkins, MN
 
Running C on an 8 bit microcontroller is nothing like using cross platform application frameworks on top of an Operating system such as linux/android, windows, mac, or iphone. If you are coding an 8 bit micro in C or C++ you can't afford much hardware abstraction at all, so it's a different can of worms.

To me if an application framework with GUI toolkits runs on windows, linux and android its close enough to "run anywhere".
 
W

William Sturm

I expect than Android based HMI's are being developed as we speak, I think there is a market. If nothing else, there would be MANY more qualified developers. I have been working towards web based technologies like HTML and Javascript for my GUI needs, mostly because that is where so much new development is happening. Being able to display remotely is a definite plus also. I am also starting to look at Java on the server side.

Bill Sturm
 
C
Yes, I was thinking more of the technologies and silicon the mobile market has spawned rather than using the mobile devices themselves. The SBCs I sent links to would be an example. The chips are extremely powerful and include a wealth of useful interfaces. They have the power to replace a PC or notebook and offer low power, no fans, and an industrial temp range. And the cost is extremely low because of the volumes brought about by the mobile demand. I could also see an industrial tablet with a ruggedized design and our favorite interfaces brought out. I think chips could compete on cost with the more traditional embedded candidates and offer PC class power for PACs as well.

Regards
cww
 
Top