Page 1 of 1
| IECC - a technical retrospective 15/03/2014 at 23:54 #57077 | |
belly buster
368 posts |
I thought I would post this here as there may be some interest. My interest in SimSig, and, to a degree, rail signalling, stems from work I did in the pioneering era of IECC. I wasn’t involved at the very start but was involved for a period during the initial roll-out to the some of the first installations. Since then I have worked for over 20 years in non-rail based industries, but I always look back very fondly at the time in rail signalling. I do not claim to be an expert, and my recollection may be somewhat foggy in the intervening time, and the world has moved in, but I will tell you a little about what I know and can remember. Computing in the 80s and 90s is not what it is now. For the younger among this group, this may seem odd, but computers were slow, pretty unreliable, and there was no internet. While we can run SimSig on a laptop at 10x speed without breaking much of a sweat, computing power back then was very modest, so specialist equipment was needed where mainstream equipment would be perfectly fine today. Some other considerations also needed to be taken into account: real time systems were certainly not the norm in this era, comparatively expensive hardware failed more often than now, and there were safety-critical aspects to consider, alongside the obvious implications should systems prove unreliable which affected operations / passengers. So the design had to take into account these challenges; this was achieved by tasks being split into components. You already know the “I” bit in IECC stands integrated; each IECC consisted of a series of subsystem that worked together to provide the overall experience. So when we talk about “ARS”, that was one component of the integrated system. ARS stands for “automatic routesetting subsystem”. However the “sub” bit was generally not used outside the IECC team. Even the graphical display was its own subsystem. The subsystems consisted of (at least), a set of SSI interlockings, a real-time transaction manager, a timetable processor, an ARS, a system monitor, a set of display units, trackball, keypad, and a data bus to allow each of the subsystems to communicate. An IECC had a logical limit to the amount of data it could handle, and therefore the size of area which it could control. This is why some sites, while in the same geographical location, actually consisted of a number of discrete IECCs. For the best part, each of the subsystems were “solid state”, meaning that there were no moving parts in the design (i.e. there were no tape drives, hard disks, optical discs etc.). Instead all the programs and corresponding storage was done on integrated circuit memory, based on Motorola 68000 architecture. These memory modules were then installed onto integrated circuit boards (similar to a motherboard) and were then mounted onto a VME bus backbone. The integrated circuits consisted of both read only and read/write memory. The read only components consisted of the application software, plus the specific configuration for that IECC. The read/write components allowed storage of transient date such as timetables, train locations etc. Setting up the read only circuit modules involved initially programming each individual chip (there were hundreds for any one IECC) using an EEPROM burner, and took a long time! As each chip looked identical, is was very important that the sequence and numbering was correct. One out-of-sequence would render the whole lot useless and the job would need to be restarted. Once all the EEPROMs were burned, they were taken to site, installed into the circuit boards (hopefully in the correct order) and plugged into the VME backbone. Generally each subsystem was duplicated with a master and a failover. Therefore if there was a hardware failure on one subsystem the watchdog would switch across to the backup. SSI was triplicated with a “majority rules” engine which could identify if one of the SSIs was providing a “rogue response” and take appropriate action. The timetable processor was a little different, this subsystem was a unix-based platform which did have hard drive and tape storage, along with comms to a central timetable database. This subsystem wasn’t duplicated as the IECC could still operate without it, though it was required for ARS routing if special timing patterns or contingency plans were in force. The majority of the systems were programmed in Pascal, with some C. The real-time operating system was actually custom written as it was considered the commercial real-time operating systems of the time were not adequate. It would be inconceivable today that you would need write an operating system as part of an IT project! I joined somewhat after the base susbsytems were developed. A large part of the roll-out was setting up data configuration for each location, testing, testing, testing, and then commissioning. Much of the commissioning involved travel to the IECC sites to do the appropriate provisioning and further commissioning testing. So I got to travel to most of the early IECCs and was lucky enough to see a lot of installations working in action. In its time it was very much revolutionary, and I would suggest far ahead of other countries in terms of signalling technology. Without getting too political, this was one area that had worked well under a unified BR that suffered as a result of the industry fragmentation in the 90s. If anyone has questions I will try and answer them. Log in to reply The following users said thank you: Farcical, Morsey, meeko, postal, BarryM, Sidestick Priority, Backup, Steamer, maxand, kbarber, Hawk777, Noisynoel, Southernrover, Signalhunter, flabberdacks |
| IECC - a technical retrospective 22/03/2014 at 08:54 #57563 | |
|
belly buster
368 posts |
I just remembered - there was a simulator subsystem too. Like a "real life" SimSig!.
Log in to reply |
| IECC - a technical retrospective 22/03/2014 at 14:24 #57575 | |
outofsection
149 posts |
This is an excellent write-up Belly Buster, but can as an ex-computer engineer, could I clarify something? The read-only memory: was it EEPROM (aka E2PROM or E squared PROM) i.e Electrically Erasable Programmable Read Only Memory which can be erased or overwritten electrically i.e. what is better known today as "Flash" memory which is the type of memory used in USB memory sticks/SSD hard drives, or was it EPROM i.e. Erasable Programmable Read Only Memory which could only be erased by exposing the little round glass window in the top of the chip to UV light and then reprogrammed by an EPROM burner? I'd feel a lot easier if it was EPROM memory as there is no way the "read-only" info could be accidentally overwritten, whereas with flash memory, it's not difficult to accidentally overwrite or corrupt the data. Sorry to be pedantic but it's an important difference! Log in to reply |
| IECC - a technical retrospective 25/03/2014 at 20:47 #57788 | |
button_pusher
56 posts |
A bit of a hardware question but why were monitors with a 66Hz? refresh rate chosen (It might not have been 66Hz but i remember it being an odd ball refresh rate that were a pain to source spares for). Delta-rail now have a new version called scalable IECC which IIRC is being used in the York area. Log in to reply |
| IECC - a technical retrospective 25/03/2014 at 21:33 #57791 | |
|
Ron_J
331 posts |
" said:Delta-rail now have a new version called scalable IECC which IIRC is being used in the York area.The two Cowlairs workstations in Edinburgh (commissioned October 2013) are scaleable IECC. Log in to reply |
| IECC - a technical retrospective 25/03/2014 at 21:53 #57794 | |
GeoffM
6376 posts |
" said:A bit of a hardware question but why were monitors with a 66Hz? refresh rate chosen (It might not have been 66Hz but i remember it being an odd ball refresh rate that were a pain to source spares for).Might be something to do with the equally odd graphics cards originally used. Back in the early 1980s there wasn't much choice in terms of the resolution required for the graphics. SimSig Boss Log in to reply |
| IECC - a technical retrospective 25/03/2014 at 22:15 #57799 | |
|
belly buster
368 posts |
" said:This is an excellent write-up Belly Buster, but can as an ex-computer engineer, could I clarify something?You are right this is an important difference and it is my poor terminology. The chips were programmed using a UV light EPROM burner as you describe. Log in to reply The following user said thank you: outofsection |
| IECC - a technical retrospective 25/03/2014 at 22:28 #57801 | |
|
belly buster
368 posts |
" said:A bit of a hardware question but why were monitors with a 66Hz? refresh rate chosen (It might not have been 66Hz but i remember it being an odd ball refresh rate that were a pain to source spares for).No clue why 66hz was used I'm afraid, Geoff's answer makes sense. Last edited: 25/03/2014 at 22:40 by belly buster Log in to reply |
| IECC - a technical retrospective 25/03/2014 at 22:49 #57806 | |
|
clive
2789 posts |
" said:At least in the 1980s, EEPROM (flash) required special voltages to write it; for that matter, so did UV-EPROM. So if you don't feed the relevant voltage to the socket, nothing the software can do can change the contents. Log in to reply |
| IECC - a technical retrospective 26/03/2014 at 06:18 #57813 | |
|
Hawk777
386 posts |
Flash memory still, to this day, requires a higher-than-normal voltage to write and erase. It is often generated on-board rather than provided externally, but it is still there.
Log in to reply |
| IECC - a technical retrospective 28/03/2014 at 14:20 #57948 | |
|
outofsection
149 posts |
This IS a most odd refresh rate. 50,60 or 75 were the normal SVGA refresh rates - the higher the better in terms of screen flicker. Mind you VGA didn't appear until the IBM PS/2 came out in around 1987! Until then it was EGA - or perish the thought (aagh!) CGA with it's whopping choice of FOUR colours! Last edited: 28/03/2014 at 14:20 by outofsection Log in to reply |