The basic motivation for this project originated with the idea of providing a music kiosk in a retail environment. I had been approached for some ideas of how it could be done. After a little basic research, I was fairly confident it could be done and submitted a proposal. Unfortunately, it never became a full project and I had to let things rest.
However, the basic ideas still kept going through my head. The basic research had brought out the work of some others. For example, the LTSP - Linux Terminal Server Project showed that the type of thing I had proposed was certainly feasible. Namely, a group of homogeneous systems being booted from a central server. This is desirable where a group of similarly behaving systems is needed for general access and one machine is as suitable as any other. Of course many people are aware of the Beowolf project that was started at NASA's Goddard Space Flight Center and has since become a commercial entity as the Beowulf project hosted by Scyld Computing Corp. However, in these cases, the cluster of computers is homogeneous. This is of particular advantage when the desired end result is LOTS of computing power and there is a central machine whose task it is to dole jobs out to machines that have available time.
During the time frame that I was working on this project, I read an article that described what I would call a poor man's cluster. My first thought was that it was merely interesting and continued on. Later, I thought that it may be applicable to this project and tried to locate it but I couldn't recall the source. A search of google brought up several interesting sites, but one in particular caught my eye. It is Cluster Computing Info Centre and contains a wealth of information on clusters. If you're interested in clustering at all, be sure to visit this one! There I found the link I was looking for to queue, a utility that allows you to run tasks on other machines in your own network. This is GNU software and looks interesting. I also found a link to the original article which described queue.
What kept running through my mind though was not a homogeneous system. What about the case where there is a large distributed system that needs coordination? Let's take as a quick example a paper mill. I have no intimate knowledge of such a system, but I envision a system whereby pulpwood must be fed into a chopper, passed to a digester, fed to a screening drum, pulled through a drying room and finally fed to the cutting and packaging area. OK, so it's a gloss-over, but you should be able to get the idea that this system is physically large and in order to achieve reasonable economics one stage must feed directly into the next with minimal storage time and human intervention. Each of these can be rather costly in today's competitive environment. Anyway, you need a control system that can meet the following requirements:
By providing computing power close to the process, it is possible to reduce the wiring requirements. This is generally costly and also presents an area where reliability can be an issue. In addition, by allocating processing power on a local basis, it becomes easy to tailor the processor to the needs. One area needs only a real time response. However, another area needs significant floating point computation with analog I/O. You can see the versatility of this approach.
If one segment can communicate directly with another, it becomes a simple task to allow the drying room to inform the screen that it should slow down as the humidity has increased causing drying times to be extended, etc. The alternative is to pass the message to a central computer for analysis and further processing before the message gets sent to it's final destination. As a side point here, if the communications can be provided through Ethernet, the implementation can ride on its popularity and the ensuing low cost. Also, distribution over any geographical region is feasible.
Most electronics designed today can hold up the harsh environment requirement. However, there is one major item that must be avoided - anything that moves. This includes fans and disks. This has been one of the primary motivations for solid state disks. However, they have always been on the expensive side. In almost any work environment an office space of some kind can be found - even if it's just for the foreman. In this space, a central server can be placed with communications links to the rest of the equipment. Here we can have the fans and disks as needed. Out in the manufacturing area, the processing power is provided with PC-104 type of equipment. There are many vendors and most will support the industrial temperature range. With this type of arrangement, it is fairly easy to meet the harsh environment requirement.
From the previous paragraph, it's easy to see that if all equipment is loaded from the central server, a software update consists of loading the new software on the server and restarting the application on the specific system affected. This restart can even be scheduled so that there is minimal impact on the production schedule.
With the above combination, reliability can be addressed to whatever degree is desired/required/affordable. For example, if you're worried about the server with its central role, put in RAID or even put in redundant systems. If you're worried about the reliability of one of the systems on the floor, redundancy is a valid option. The design of such systems is not trivial, but it is certainly feasible. What about the underlying network? That can be redundant as well. It will double the requirements for interfaces, but the possibility of saving the production run when a fork lift cuts through the cable may be worth it! Note: Reliability is not an issue addressed in this work.
OK, so what is being addressed in this work? There are two basic aspects. The first is just the basics of how do you define and set up such a system. I will start out by installing a basic server configuration. This will intentionally be very basic. Secondly, I will set up a 'slave' PC. It is my desire to be able to boot up such a system totally diskless - not even a floppy. The second aspect is how such a is system initialized. At this point in time, I do not have a specific task in mind, but I'd like to have the 'slave' PC boot up and start running some specific task to demonstrate the unattended capability. It would be nice, if the 'slave' PC could be headless (no keyboard or monitor), but that remains to be seen.
Copyright © 2001 David J. Pfaltzgraff, all rights reserved.