Windows Web Browser Crashes

R

Ranjan Acharya

Which web browser are you referring to? There are ones such as a tiny one from QNX that work from a floppy disk and then the monsters from other vendors that sort of work most of the time.
 
M
Eduardo,

Thanks for your input. I was more interested in how well-behaved the browser itself was. I haven't had too many responses, probably because not too many people are using browsers as operator interfaces in industrial applications.

Whenever I start thinking about a browser-based operator interface, I dream about how easy it would be to maintain only one application on one server computer. Then I download the latest Netscape/Internet Explorer for my own computers and watch it produce problems I never had before. I then think about how much fun it would be to try and support Internet Explorer versions 3.x through 6.x and every version of Netscape, Opera, and Mozilla for multiple operating systems, and my dreams slowly turn into a nightmare. But then again, my customers have a tendancy to make my life difficult by making decisions that optimize their operations, and not mine...

Let me change my question. If I could force my customers to use a certain web browser/operating system combination (much like a kiosk), is there a combination that would be consistently reliable?

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

 
M
Ranjan,

I'm now open to all choices. The QNX offering
(http://www.qnx.com/demodisk/) also includes a web server, but does anybody know how reliable it is? Is there a reliable web browser from any manufacturer on any operating system available?

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

 
I believe that there are several dissimilarities between browsers, but you don't have to ask your clients to change their preferred platform. RH7.2 comes with Mozilla 0.9 free, or you could select 0.7 for backward compatibility, IE5.5 has been shipped from the last several years. Software is generally available on CD's for free and hence client is likely to have access to such versions which give you advanced functionality.

You will have to select a base level of browser that the client requires to use. This will be due to the functions and commands used in your application.

Some points for better compatibility.

Standard HTML or preferably XML.
A Database to store data, history etc.
Simple javascript commands that are supported in a number of browsers. Use commands like navigator.appCodeName, navigator.language and other such commands to find the type of browser and using if then conditions, write different scripts for different browsers, in case your function is not supported in one.

Generally, you can come to a set of commands supported by most browsers. However, you will have to select your base level (Minimum Netscape 6.0, Mozilla 0.9, IE 5.5 etc.) and then work ahead.

Browser downloads are free and hence you can easily request your client to upgrade the browser. Having a team that can write plugins for browsers will be a big help but is not a must.

Those were the issues:
On the positive side
We are talking about using a open protocol that has cross platform support. Making it multilingual is very easy. Easy availability of browser and web programmers. People are well aware of the technology. Future integration of the client companies across the globe becomes child's play.

Anand
 
G

Greg Goodman

> Thanks for your input. I was more interested in how well-behaved the
> browser itself was. I haven't had too many responses, probably because not
> too many people are using browsers as operator interfaces in industrial
> applications.

Mark,

People are using browsers as part of their HMI although not, for the most part, their primary or only HMI.

I've got clients using browsers as an integrated interface for their process data, their network status monitor, access to their shift reports and lab reports and recipe database... But the browsers are not dedicated to the process HMI task. These people are using the browsers that sit on their desktops, the same browsers they use to surf the net, check their email, play Java games, etc. For most, that's the whole point behind browser support in control systems - to let somebody sitting in an office have an interface to the process without having to install a new program.

That said, the well-behavedness of the browser is largely a function of what it's asked to handle. Almost any browser on the planet is perfectly robust if all it's used for is rendering well-formed vanilla HTML, preferably without frames or tables, definitely without style sheets, without Java or Javascript or embedded Tcl, without plugins for Flash or Windows media or RealPlayer. It's when you start exercising the more complicated stuff that things get tricky; different browsers (and different versions of the same browser) do better and worse jobs of
implementating various features.

For example, most of my Netscape 4.x crashes have resulted from displaying pages that contain Javascript. (I don't know if it's a matter of bad Javascript support, or poor self-protection against bad Javascript. Doesn't really matter.)

> Let me change my question. If I could force my customers to use a certain
> web browser/operating system combination (much like a kiosk), is there a
> combination that would be consistently reliable?

I don't have an answer. But I think your choice depends on your answers to the questions

"What content does the browser have to handle?"
"What features does the browser have to have?"

My preference would be the smallest-footprint simplest open source browser that actually met the requirements. A browser that is effectively the GUI for an application can dispense with bookmarks, the "Back" button, user-enterable URLs, etc. (The responsibility for managing navigation rests, as it should, with the interface designer, the person who defines the web pages and the links between them.) I can
do without editable personal preferences, customizable fonts and colors, the ability to flush the cache, I'd like to be able to turn off
the source viewer, disable the history list... you get the picture.

Personally, I *would* want Java capabilities, because HTML is a bit weak for live data. And there are a few other things I'd want. But all the doodads that make the average desktop web browser such a feature-rich general-purpose end-user-oriented desktop commodity are part of what
makes them, in my opinion, poor choices for control and automation. Give me simple, clean, and dedicated.

This is beginning to sound like the spec for a new open source project, or for a cut-down version of Opera or Mozilla...

Regards,

Greg Goodman
Chiron Consulting
 
C

Curt Wuollet

Hi Mark

I haven't seen a really reliable web browser but that's with all the diversity, good and bad on the web. I would expect they would all be a lot more reliable in a controlled environment with well written basic html as input. I may have to take a look at the QNX offering. The reliability would certainly improve dramatically if someone made a bare bones browser for that purpose. Even smaller than Opera or Galeon. Lynx is very reliable but is text only. There has been too much emphasis on features and flash (no pun intended) and winning the tags race rather than on stability. Sad to say that even Linux won't help much here. The web is such a moving target that browsers will probably never really stabilize. Good sites don't crash browsers so there is hope. If I stay away from glitzy sites and active server pages and javascript, I can run Netscape 4.76 for weeks. One visit to some commercial sites destabilizes it.

Regards

cww
 
Apache httpd or the newer version are one of the most reliable web servers available for free from Linux and are being used in mission critical
applications. I believe that these Web servers are the world leaders today. Microsoft's IIS, well I do not have experience with this Web server, but i am sure data may be available on
the net.

The Crash that occurs will happen on the Browser end i.e. IE5.5, or Mozilla or netscape or others.
I.e. client side software's.

But what needs to be kept on mind is:

Of the Three different DCS systems, One TMR system and Seven different SCADA/HMI systems that
I worked with or commissioned in my career in several installations across the globe, not one was crash proof. They would hang at some frequency of a week to a month and half. However, there would be a backup or several operator stations and these would be used for controls.

Again, the reliability of Browser SCADA would depend on the strength of programming in the application. Most browsers are ruggedly built, but face certain problems due to incorrect programming techniques.

Looking at the Advantages:

A browser SCADA will provide the user with a software which is future proof.

A change in OS like shift from MS to Linux to Mac to Sun or OS2 or any other OS will not mean changing the programming or making changes in
application program data.

Windows has gone from 3.11 to XP and every time, there have been some or the other compatibility issues. The wheel is reinvented overtime, the OS undergoes a change. This need not be the case if the SCADA is a Browser SCADA. Then you can
work right from Win 95 to XP or any other OS that supports that Browser Version.

Hardware limitations also get removed, as HTML is chosen is supported from 386 onwards.

WAP enabling becomes a simple task of dial-up and presenting messages using appropriate software.

Integration is simple, a simple change in the Web server area, automatically provides all the users with the requisite data.

For critical applications, however, it would be appropriate to use a redundant server with Raid disks from a proven vendor and running strong Web Server software and database. The front end machines or PC's should be more than one so that the crash of a browser does not affect
operability.

Please note that in a machine, the crash of one browser need not mean rebooting the machine as is the case with several SCADA systems of the day.
You can also put two browsers like Netscape and IE in one machine and in case one of them crashes critically (cannot be started without rebooting),
then you can always start the other browser without rebooting the machine, and your application would still work.

The advantages of a browser SCADA are tremendous, but mind you, you are not likely to get a lot of work in terms of reinventing the wheel every now and then. You won't be selling updates and patches, just because the OS is upgraded or stuff like that.

If you look at several SCADA's of the day they have had to reinvent the wheel due to changes in OS, Y2K and stuff like that. Some of them may not be .NET compatible and like the CD writing software's that were free with the CD-writers
and would work in older Windows version and now you have to pay and upgrade the writers for XP,
you may have to add patches or upgrade the SCADA systems of the day.

one of my experiences with a popular SCADA system is like this:
1st worked with a SCADA on industrialized hardware which used UVEPROM's etc., Z80 CPU but it was hardware dependent.
Then came a HMI on DOS.
This was followed by win 95 system.
This would not work on Win 98.
This would then work in Win 98 release 2.
There was a problem in basic alarming function when the software was upgraded to 32 bit.
In other words, the same two dimensional graphics were probably reinvented several times.

Not that the company did not provide newer features, but the effort wasted in reinvention,
could have provided advanced process control logic's, perhaps three dimensional graphics, and the likes.

using standard browser functions means that the core programming issues with regards to OS upgrades or newer OS's are handled by the people making browsers and continuos improvement and adding to the functionality of the SCADA becomes a reality.

Anand
 
M
Anand wrote:
<clipped>
>
> Please note that in a machine, the crash of one browser need not mean
> rebooting the
> machine as is the case with several SCADA systems of the day.
> You can also put two browsers like Netscape and IE in one machine and in
> case
> one of them crashes critically (cannot be started without rebooting),
> then you can always start the other browser without rebooting the machine,
> and your application would still work.
>
<clipped>

Excellent advice, although I have seen cases where Internet Explorer brings the whole operating system down (in particular, the "explorer.exe" task which controls drawing images on the screen). I think in most cases, having an alternative browser available would be sufficient so that the computer could be rebooted at a time of the operator's choosing. Thanks for the excellent suggestion.
 
C

Curt Wuollet

Well. the question was specifically regarding browsers. If you were asking about clients or an alternative to using html, I could suggest some rock-solid solutions. If you do want something inexpensive, new and novel as web clients, I would look into the NIC.
http://www.thinknic.com.
This is a user proofed thin client that runs Linux and Netscape 4.7x (possibly the most stable) for html and of course, is configurable to
an X terminal and should be a good candidate for VNC as well. This way your options are open no matter what the back end is running on. It has ethernet and a modem built-in for remote access.
NIC doesn't know all this as they sell it as an internet access appliance for your grandma or schools. It should be great in the role of an industrial display terminal with the addition of a piece of tape to seal the cdrom drawer. Low power, low heat, boots off CDROM and has no hdd. $329.00 with monitor kbd and mouse. For only $1000.00 more you can get a very similar but very much less flexible "industrial" thin client. But, where access is easy, I doubt the "industrial" thin client will outlive three of these. Any reasonably competant Linux guy can show you the multiple personalities. And there are HOWTOs to netboot the thing and eliminate the CDROM. It should then be pretty reliable. If the NIC is too avant garde I'd use commodity Linux PCs. I can
get suitable machines burned in for thousands of hours for about $250.00. And they would be even more flexible than the NIC. Neither of these has any per seat licensing or recurring costs or for that matter, initial software costs. The PC's would have some support costs because users would do other things.

I'm fleshing out this example for a reason. I normally get paid to do this kind of stuff by people who need value. Because I can provide much more value with Linux, I get labeled as a zealot and asked not too politely to mind my own business. But this is everybody's business and will provide robust clients at a small fraction of what it would cost with any other approach. And it will make no difference to the user what OS is running on the appliance if all they see is what you provide. Network clients are one of the best examples because they are used in multiples. I used the NIC because it's the answer to the
question: "How do I provide a robust browser for the least cost". Then it does it by using commodity technology and Linux. Price a hundred of these against a Citrix setup. Then add in support :) The approach isn't better because it uses Linux, It's just better.

There is tremendous potential if people can reach a little beyond their comfort zone and see what I'm really selling. I should probably reserve it for paying customers :)

I would look at VNC instead of a browser interface or X. It's cross platform and better suited for industrial graphics than html and free. X would cost too much unless your back end
was Linux also. Think of it as being like pc anywhere without needing a local screen.

But you'll probably end up using something much more expensive and much less flexible and almost certainly running Windows. I'd bet coffee on it.

Those would be my thoughts if you wanted robust alternatives.

Please don't think I'm picking on you, I was making a point.

Regards

cww
 
M
Curt Wuollet wrote:

<great information about http://www.thinknic.com. clipped>
> Please don't think I'm picking on you, I was making a point.

Great points. If you'd like to pick on me, I wouldn't mind that either
(especially when you back it up with excellent suggestions).

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
 
C

Curt Wuollet

Geez... I might have lost a cup of coffee. For a lot of NIC ideas, check out Embedded Linux Journal, they held a contest to see what people could do with a NIC.

Regards

cww
 
Top