Windows Web Browser Crashes

M

Thread Starter

Mark Wells

Hello,

I was just curious how well web browsers are working as operator interfaces in industrial applications. Any feedback from list members using web browsers in this way would be appreciated. I'm particularly interested in
crash frequency.

As reported in a recent Infoworld column and documented by Bugtoaster (www.bugtoaster.com), three of the top ten applications that cause Windows computer crashes are web browsers (Internet Explorer, Netscape, Opera). Unfortunately, the statistics don't show what operating system was involved in the crash (Windows 95 vs. Windows NT or Windows 2000), and there is no way to determine if the computers involved in the crash had configuration problems. As well, I imagine that the web browsers are used much more frequently than other applications, further skewing the results...

Sincerely,

Mark Wells
President
Runfactory Systems Inc.
http://www.runfactory.com1235 Bay Street, Suite 400
Toronto, Ontario, Canada M5R 3K4
Ph. 416-934-5038
Fax 416-352-5206
 
P

Patrick Cross

I've found it's not so much the browser that is the problem, but more what you're trying to do with it.

Standard HTML and basic scripting works well and
browser crashed are rare if you stick to those.

When you start using components & plug-ins (ActiveX, Java, etc), you're more exposed to the quality of the component .. and you're also using features which are not as widely used, tested and debugged.

This is where I see the difficulties of using a
browser as an operator interface at the moment. A
browser is really designed for that purpose and not enough people are doing it to make it ensure its reliability.

Regards

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
[email protected]
 
Hello Mark Wells,

I have put a web Browser based SCADA possibility in www.smbd.org, under section 'Automation'. This is a simulation, which I have successfully
run for a couple of days in Linux 7.1. I have tried for a few hours in Windows. I am adding a real time trend to this trial. You can try the app.

It works properly on netscape 6.0, 6.1, Mozilla 0.7 and IE5.5. Some of the commands used are not supported by older browsers.

In case the code is bug free, then browsers can work for days and weeks. I think that should be sufficient for applications that do not use
safety interlocks through HMI. In fact it can be a good substitute for the several SCADA and HMI apps of today.

Anand
 
C

Curt Wuollet

It might be germane to mention that one of the reasons for browser interfaces is so you don't have to run Windows.

Regards

cww
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Maybe so, except for the systems that then stab you in the back by requiring IE, not compatible with netscape. This *WOULD* be foolish. There are some companies ( the one I work for included) that have thousands of machines all running Netscape, and IE is not used nor is it updated. If you are going to go thru the effort of providing a browser interface, make it compatible with other systems.

Of course, the cynics among us will point out that the browser interface exists just so that the vendor doesn't have to write a client app.

--Joe Jansen

 
Web browsers are a poor choice for a HMI. Most problems are associated with the version of the browser and the machine processing the data. Problems will be noticed if you update to a newer browser, such as IE 5.5

Westinghouse Process Control
Pittsburgh, PA 15238
 
C

Curt Wuollet

Hi Joe

That would sure be a question I would ask and verify up front. What good is a browser interface that doesn't interoperate? Especially after today when your MS taxes are going to skyrocket and lots of folks are gonna dump MS. My phone inquiries are really picking up. I guess all clouds have a silver lining.

Regards

cww

 
Code written should be compatible with most browsers. An initial code written by me would not work in IE5.5 which was due to IE5.5 not
properly handling the positioning of nested DiV tags.

My web site experience tells me that more than 95% of hits were from IE5.5, netscape 6 and 4.77 mixed, Mozilla 0.7 onwards.

A good benchmark would be to test the application in netscape 6.0, IE 5.5 and mozilla 0.7 . If it works on all three, then you have a system
capable of working on almost any platform (modern ones that support browsers).
 
M

Michael Griffin

Joe Jansen wrote:
<clip>
>Maybe so, except for the systems that then stab you in the back by
>requiring IE, not compatible with netscape. This *WOULD* be foolish.
<clip>
>If
>you are going to go thru the effort of providing a browser interface, make
>it compatible with other systems.
<clip>

I suspect that mobile devices with integrated browsers are going to develop to the point where any web based MMI software which requires a specific web browser or operating system will prove to be a developmental dead end. Within a few years most web access will *not* be done with a PC, and people are going to expect to use these devices to see their plant status.

I can forsee this as being particularly useful in large process plants where you may wish to see a particular process variable without having to travel to the control room or other fixed point. Under this scenario, tying yourself to a particular set of proprietary browser extensions would be foolish.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
C
This entire problem is caused by the fact that a certain company's development tools use proprietary extensions. Since that company has a monopoly in the automation world even more than the larger world, it's unlikely to go away soon. In fact, even the embedded stuff is likely to produce dot something or other crap to ensure
that it's a real pain to interoperate. It's not foolish at all for them to do this, it's merely foolish to use their tools and software exclusively with all the better options around.

Regards

cww
 
A
There is one serious problem with this idea -- and that's that web browsers suck for HMI use. A simple HTML page is loaded only once and has no dynamic updating. You've got to write a Java applet, or use some other means that extend basic HTML to give it the capabilities you need.

If you use Java, you get to deal with that. Despite Sun's propaganda, it isn't a write-once, run-many language, its more of a write-once,
test-on-many language. There are plenty of things to use instead of Java, but I thought the idea of using a web browser was to use a standard....

Even with some sort of "standard" or "non-standard" extension to a web browser, it's still a better option than a PC. You don't need Windows to just run IE. Tou don't need Linux just to run Konqueror/Mozilla/Opera. (Netscape doesn't get a mention here since all its versions are very bad at HTML rendering, and the Linux version of Netscape is the most unreliable and crash-prone web browser I've used since 1996).

Alex Pavloff
Software Engineer
Eason Technology
 
M

Michael Griffin

At 10:06 09/10/01 -0700, Alex Pavloff wrote:
<clip>
>If you use Java, you get to deal with that. Despite Sun's propaganda, it
>isn't a write-once, run-many language, its more of a write-once,
>test-on-many language. There are plenty of things to use instead of Java,
>but I thought the idea of using a web browser was to use a standard....

There's probably a lot of problems to solve in getting useful displays to work on various devices. There is likely to be such a large general market for it outside of automation though, that you should be able to buy software toolboxes off the shelf. I don't see every MMI software vendor being able to test every possible device. Rather, I see them buying a toolbox from someone who worries about these things for a living.

>Even with some sort of "standard" or "non-standard" extension to a web
>browser, it's still a better option than a PC. You don't need Windows to
>just run IE. Tou don't need Linux just to run Konqueror/Mozilla/Opera.
<clip>

I think the idea is to stick to features which are widely accepted published industry standards rather than "defacto standards" or proprietary extensions. I should be clear that I mean you should avoid something that locks you into a particular operating system or platform, regardless of whatever that happens to be. MMI systems will have to work with everything from large screen thin client displays to small hand helds to PCs.
Today people when people think of a web browser, most of them think of a PC. However, in a very few years that will no longer be true. A system that works today will be an embarrassing white elephant tomorrow if this is not taken into account. You will have a very hard time explaining to someone why they can't see a level reading on their pocket web browser from the tank
beside them when they have no problem using it to see the air temperature in Iqualuit.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
C
I agree, Low Bandwith X with compression would be my choice. Or possibly something like VNC but pared down to HMI essentials. Browsers can be good for some uses, a busy HMI probably isn't
one of them. The Java situation is tragic. It could be a lot better if the 800 pound Gorilla would play nice and they really standardized some subset. By eschewing GUIs, excellent
responsiveness can be achieved at even serial speeds. A new type of engine that makes use of the techniques developed by the gamers to lower needed bandwidth could do an excellent job for even animated displays. All it would take is an Open standard and strict dedication to purpose. Of course, inside a month there would be 50 incompatible closed versions. Sigh....

Regards

cww
 
V

Vladimir Zyubin

Hello Alex,

On Tuesday, October 09, 2001, 11:06:30 PM, Alex Pavloff wrote:

>> I suspect that mobile devices with integrated
>> browsers are going to develop to the point where any web based MMI
AP> software which requires a
>> specific web browser or operating system will prove to be a
>> developmental dead end. Within a few years most web access will *not* be
>> done with a PC, and people are going to expect to use these devices to see
>> their plant status.

AP> There is one serious problem with this idea -- and that's that web browsers
AP> suck for HMI use. A simple HTML page is loaded only once and has no dynamic
AP> updating. You've got to write a Java applet, or use some other means that
AP> extend basic HTML to give it the capabilities you need.
[...]

AFAIK, HTML has dynamic updating... the command "refresh".

And, yes, Java is a bad means for the task... and yes, rather because of bad standartization.
As well as the version incompatibility both of IE and Netscape makes the browsers unacceptable for HMI use.

But kind of "exhanced" HTML as a language to describe user interface could be an exellent means to solve the incompatibility problem and to make our life easy.

Could XML be the language? I don't know... the answer is rather negative.

--
Best regards,
Vladimir
 
A
> I think the idea is to stick to features which are widely accepted
> published industry standards rather than "defacto standards" or
proprietary
> extensions. I should be clear that I mean you should avoid something that
> locks you into a particular operating system or platform, regardless of
> whatever that happens to be. MMI systems will have to work with everything
> from large screen thin client displays to small hand helds to PCs.

It sounds like a great idea -- and I think/hope there will eventually be enough power down on the hand-held end to allow the same "user experience"
on all levels. However, even if you have the sheer computing power to run the same Java applet/or equivalent "standard web HMI", you've still got the plain fact that a hand-held is a lot smaller than a PC, with completely different screen geometry, and usually lacks a keyboard. Sure, it can be done, but I don't think you're going to see much push for making interfaces
"simpler" just so you can access them on your mobile phone. There's a certain point at which it becomes silly.

> Today people when people think of a web browser, most
> of them think of a PC. However, in a very few years that will no longer be

> true. A system that works today will be an embarrassing white elephant
> tomorrow if this is not taken into account. You will have a very hard time

> explaining to someone why they can't see a level reading on their pocket
web
> browser from the tank beside them when they have no problem using it to
see the air
> temperature in Iqualuit.

I don't doubt that. However, I'm going to make a bold prediction here and say that there will be NO standard for HMI via web browsers that will be
acceptable to the Allen Bradley's of the world & the Curt Wuollets of the world. :)

Alex Pavloff
Software Engineer
Eason Technology
 
C
Hi Alex

There will be an eventual meeting of the minds, OSS folks run the net. Of course, then there are the people who are trying to patent it.

Regards

cww
 
M

Michael Griffin

At 09:43 10/10/01 -0700, Alex Pavloff wrote:
<clip>
>It sounds like a great idea -- and I think/hope there will eventually be
>enough power down on the hand-held end to allow the same "user experience"
>on all levels. However, even if you have the sheer computing power to run
>the same Java applet/or equivalent "standard web HMI", you've still got the
>plain fact that a hand-held is a lot smaller than a PC, with completely
>different screen geometry, and usually lacks a keyboard. Sure, it can be
>done, but I don't think you're going to see much push for making interfaces
>"simpler" just so you can access them on your mobile phone. There's a
>certain point at which it becomes silly.
<clip>

I don't think you would want to get the exact same display on the hand-held that you do on the large screen thin-client. Instead you would
only get smaller bits of it. That is, while the large screen may show you a complete over-view of a system, the hand-held would only show you part of it at a time. The same would apply to opening a small window on a PC. The question then becomes whether this means that the application developer
needs to develop two sets of screens, or whether there can be some more automatic means of creating this.
I don't have any particular ideas on how to do this, but there could be some solution based on the fact that the access for different devices may be for different purposes. The operator using a big screen wants to control
or monitor the plant, while the person with the hand-held (who may be out in the field) probably just wants a particular reading.

What about providing access to sets of tag values? When you define a tag, you could associate an optional control graphic with it that is not visible on your user screens, but can be called up independently. Your hand-held could then call up a web page with lists of these tags, allowing you to pick one. That way, if you are standing beside a tank and you want to know how much is in it, you can get a reading without phoning someone up and asking them.

You could call these the "integrated" view of a screen graphic or control (when incorporated into a conventional control screen), and the "independent" view (when viewed in isolation). The "integrated" view may show an animated tank filling and emptying, together with the pipe connections which show how the tank relates to the adjoining equipment.
The "independent" view could be something simpler, such as a bar graph and numerical reading and not show any relationship with other
equipment. To see the independent view, you would select the "screen" and get a list of the controls you can look at. You would then pick one of those and get the reading you were looking for.

This would seem to limit the amount of extra work required to create an MMI system with this capability. The user could decide which web page (integrated or list independent views) to look at, based on their needs and the capabilities of their devices.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
>There will be an eventual meeting of the minds, OSS folks run the net.
>Of course, then there are the people who are trying to patent it.

And there's Microsoft, who doesn't want to run the net or patent it. They just want a commission every time someone *uses* it.

Rufus
 
W

Wilson Barbosa

I have seen that all supervisory system under Windows and Windows NT allways are showing some crashes. I won´t use any browser on it if system under control is very very important to the process been controlled.
 
E

Eduardo Manuel C. Cipriano

Hello Mark Wells

I just want to reply to your inquiry on web browsers being used as Operator Interface, well I have personally simulated Web browser when I was in Singapore Last year at the Schneider Training basically it works like an ordinary Operator Interface it has all the graphics/control/monitoring capabilities BUT !!! the main problem is that Industries does not tend to use it because it will use Ethernet protocol as for my experience this protocol is not reliable enough because you cannot configure data sent/receive in different schedule so whenever you have a lot of data crossing in your network you cannot instantly shut off or turn on a particular I/O in your system it will take delay from 3 - 10 seconds responds of your system so basically these are not used in Industries right now. This protocol is only used for Information Level only producing reports for example, Right now they are developing the Fast Ethernet Protocol which they will make the existing Protocol a thousand or more Faster so that whenever we use it in our Web Browser Operator Interface the delay of the data will only be on Nano Seconds..........

Anyway I hope you have learn something if you need any help you could email me [email protected]

Eduardo Manuel C. Cipriano
Sr. Systems Engr.
Yokogawa Phils INc.
 
Top