Technologies being accepted

T

Thread Starter

Tom Bullock

In the automation of discrete and process manufacturing, many technologies are presented at conferences and seminars, but few gain wide acceptance on the factory floor. What technologies, not prevalent 3 to 5 years ago, will have gained acceptance on the factory floor within the next 3 to 5 years.

For instance, Linux has been around for a long time, but few end users request it nor do system integrators push it. The same for OMAC and open controls. Wireless, on the other hand has gained good acceptance. What about embedded web servers, video, enterprise software being offered as part of the automation package. Anyone have an opinion on what is making it now or will in the near future?

Tom Bullock
[email protected]
 
If I knew the answer to all that for sure, then in 3 to 5 years I would probably be pretty rich. I can take a shot at it though.

> For instance, Linux has been around for a long time, but few end users request it nor do system integrators push it. <

It has taken over a big chunk of the embedded OS market, so it's probably already in a lot of factories in devices that people buy. The users (and the salesmen) just don't know it. Engineering desktops however will use whatever the rest of the business uses, and the answer to that is a bit outside your original question.

> The same for OMAC and open controls. <

I don't think we will see anything from the original OMAC companies (GM, Ford, Chrysler), as I don't think they will have the personnel left who could implement a change like that. It could happen with some other large company or group of companies. If they do it though, I think it will be driven more for a need to support additional capabilities (e.g. better integration into the rest of the business) rather than as a direct cost saving measure.

> Wireless, on the other hand has gained good acceptance. <

In some applications. But that isn't really new though.

> What about embedded web servers, <

Yes. We will see embedded web servers in everything that requires configuration and diagnostics where they will replace traditional configuration software. This is much simpler from the point of view of both the manufacturer and the user. You don't have to match the device firmware version to the configuration software version and deal with all the consequences with one or the other being out of date. Also, the user doesn't have to install myriad small software packages (this is a problem in a lot of companies due to IT policies).

It will quite feasible to use a web browser to display live ladder diagrams for on-line troubleshooting (I'm working on that in fact). We won't see them replace traditional PLC programming packages within that time frame though. (See below though).

> video, <

If you mean area video monitoring then no, except in limited applications. Privacy laws in many countries make siting of video cameras inside a building difficult except in traditional after hours and perimeter security applications.

If you mean vision systems or point monitoring, then yes, but that is nothing new.

> enterprise software being offered as part of the automation package. <

If you mean ERP integration, Siemens has already been (was?) offering that as a custom service to their largest customers. They had a special division set up for it (they even had their own private Linux distro). I don't know if they still do this though. I can imagine a lot of interest in this area from other vendors because of the amount of money involved in typical ERP installations.

However, they will find the ERP vendors going after the same market from the other direction. The biggest problem I see for the automation vendors is that customers will suspect them of trying to use this as an excuse to replace a lot of existing control systems with new hardware from that vendor. The other problem is that the automation vendors don't really have any applicable skills in this area.

> Anyone have an opinion on what is making it now or will in the near future? <

I suspect the most significant trends will revolve around networking, communications, the flow of information, and changes in basic assumptions about where web technologies can fit in. People working in automation will be expected to know a lot of things that they have so far been happy to leave up to IT specialists.

Now, here are a few items that fall more into the field of "wild speculation".

Wild Speculation #1: New Business Model for SCADA vendors.

Large scale SCADA systems for electric power, water, pipelines, refineries, etc. may become sold on a "single vendor solution" model. The SCADA vendor offers a CD (or DVD) with *all* the software needed for a system, and takes complete responsibility for it, including upgrades, security patches etc. That includes OS, databases, web servers, drivers, the SCADA itself, development software, etc.

This would be driven by demand from customers who want someone else to take responsibility for security and updates. The customer would pay an annual maintenance fee and in return the SCADA vendor would provide guarantees for security fixes and up times.

The basis for the above speculation is that there has been a lot of discussion in the utility business lately about software security and who should be responsible for it. The utilities don't want to deal with it. The SCADA vendors don't want to deal with it. At some point though, some vendor may decide to embrace this nettle rather than reject it. It offers a good annual revenue rather than the occasional sale. This is the direction that enterprise IT industry has gone in, and large SCADA systems have a lot of resemblances to that.

It's a bit different from the older totally proprietary SCADA model though, as they won't have to develop the whole stack as there is now a large open source supply of commodity components (OS, database, etc.) they can tap.

In this model, the largest SCADA vendors would have the advantage as they could hire the staff with the appropriate expertise. Smaller vendors would have to subcontract some of the expertise, and so would be at a disadvantage in terms of reaction time.

Wild Speculation #2: PLC vendors offer their programming software as a web service.

PLC vendors could offer their programming software as a web application. You would go to their web site with your web browser, log on, and you get a web page that lets you write PLC software (in ladder, SFC, IL, or whatever).

It won't look like like a traditional web page. It would be very interactive and graphical (have a look at the video for the Google Wave demo if you want to see what I mean). The technology for this is now built in to most of the latest web browsers (pretty much all of them except MS IE). The programming toolkits to make it practical are now appearing (GWT, PyJamas, etc.).

The business justification is there too. You would pay for the software according to how much you use it. Vendors could offer different plans to different types of customers, and heavy users would pay more than occasional users.

On-line troubleshooting and on-line program changes in PLCs could take place through an embedded web server in the PLC. This wouldn't be as sophisticated as the main web application hosted on the vendor's own site, but it would be good enough for what it is intended.

I've looked into what would be involved in doing this for my own purposes, and it looks quite feasible. The biggest challenge is keeping interactivity at acceptable speeds when working with the vendor hosted application. A locally hosted app is much easier in that respect.

There are a couple of big arguments against it though. One is that customers might reject it as being too unfamiliar. The other is that for vendors it means designing all new software from scratch instead of building on their existing products.

On the other hand, it means that people who write lots of PLC programs would have whatever software they need available to them on a project by project basis. People who just want to run the PLCs in their factories wouldn't need the advanced programming software, and they could just do their troubleshooting and bug fixing using the version that came in the embedded web server in the PLC.
 
Top