Take note that these are notes made during the project. They are items to take into consideration during an actual implementation.
December 23, 2000 One of the problems encountered during this project was that most items were in a state of flux. Even the primary web site moved! The work I did used Etherboot version 4.4.4. Today, the officially released version is 4.6.12. I didn't bother updating each time as my cards were old NE2000 compatible ISA cards. Most of the changes that I followed were related to newer (i.e. PCI) cards. Anyone starting on a venture such as this should obtain the latest copies of both the source code and the documentation!
January 2, 2001 While catching up on my reading today, I picked up an old issue of EETimes (Issue 1133, September 27, 2000) where they were paying tribute to those they thought were the primary architects of the current Internet. One of those being recognized was Rob McKeel who is VP Operations at GE Cisco. You can find them on the web at GE Cisco Industrial Networks . I found the site interesting in that they are pursuing pretty much the same lines as discussed here. However, as would be expected, their emphasis is on selling networking hardware and services. They do provide thin clients (see: GECisco and follow the links). However, their thin client, the CoBox DR1 is rather pricey for the capabilities. I feel that the approach that is discussed here will provide much more bang for the buck - even if you consider the costs of industrial grade hardware.
January 7, 2001 One of the problems facing an operational system is how to manage the assignment of the MAC addresses when repairs are required. Projects such as LTSP and others dealing with a homogeneous network typically will use DHCP and select an IP address from an available pool. However, in this environment, the IP address may be key to communications between various machines. (Even if DNS is used, the IP address is ultimately the final link.) For example, it will be the IP address that determines that this machine acts like a drying room controller while another is a fermentation vat monitor. One thing I have considered is to use some form of hardware key that identifies the functionality. In this case, all machines would boot up identically and assume their individual personalities after the run-time program comes up. In this scenario the machines would be IP ignorant and thus could not talk directly to each other, but would have to pass messages through the server. This has its advantages and disadvantages. The trade-offs would need to be evaluated by the system's integrator.
January 9, 2001 Here are a few random thoughts that have occurred while working on the system. The first is a comment on the general trend to make things easier. For example, almost every package now comes with some form of 'install' routine. These are nice in that they put things in the right places for a normal system. However, in this case, the desired place is somewhere in the /tftpboot/... structure as compared to the /bin/... structure. This has made it a pain to find all of the related files and get them put in the right place. This should be a minor problem when working with a control system in that the final application is generally going to have a limited set of files.
While working with this system, I would power it down each night. Not that it was needed, but the old practice of saving energy. Through this I learned that everything relied on the server. This should be an obvious thing, but it was much more obvious when I had to sequence each machine on when I brought it up and then do the reverse as I shut it down. This would mean that to perform maintenance on the server, the whole system would need to be brought down. We may need to rethink this in terms of a mission critical system! Some aspects of this could be solved through judicious system design, but it would remain a problem during the life of the system.
One of the issues that I thought of but did not take the time to pursue is that of implementing a RAM disk. Proper use of a RAM disk would reduce the network demands. However, critical data that must be retained needs to find its way to a hard disk as soon as possible in the event of a system shutdown.
January 12, 2001 It is very interesting to note that in the January 2001 issue of the "IEEE Spectrum", which I just received today, there is an article ( Ethernet's Winning Ways) by Gadi Kaplan, page 113, which describes the increased use of Ethernet on the factory floor. They discuss the work of GE-Cisco as well as Jetter AG of Ludwigsburg, Germany and others. The interesting thing to note is that they basically have the 'mainframe' mentality which requires deterministic delivery. This results in a higher system cost even though they mention cost as being a driving factor. The approach that I'd like to promote is that the 'determinism' is defined locally. The Ethernet is merely the medium for message delivery. A good analogy is the trainmaster who tells his helper, "Now, boy, when that clock says 12:00 on the nose I want you to ring that bell." Whereupon, his youthful helper saunters over to the bell and stands ready. At precisely 12:00, the youth reaches out and rings the bell. There was no need to have the message delivered precisely at 12:00 when there was ample knowledge and capability to perform the task correctly and accurately. With a truly distributed system, the knowledge and capability will be available when and where they are needed. (That is, provided correct system design and implementation!)
Copyright © 2001 David J. Pfaltzgraff, all rights reserved.