CAE Inc.

INTRODUCTION

This was my second job! Working for CAE Electronics as a Systems Analyst / Developer was the most interesting and challenging job I had in my forty year IT career.

Company History - Inception

CAE Inc. (founded as Canadian Aviation Electronics) is a Canadian manufacturer of simulation technologies, modeling technologies and training services to airlines, aircraft manufacturers, healthcare specialists, and defense customers. Today, CAE has manufacturing operations and training facilities in 35 countries.

CAE was founded in 1947 by Ken Patrick, an ex-Royal Canadian Air Force (RCAF) officer. After World War II there were many people that had developed skills in aircraft manufacture and avionics. Ken's vision was to take advantage of a war-trained team that could leverage their skills in other areas. The company's initial products were avionics calibration and repair. In the 1950s it also assembled DuMont branded televisions under license from DuMont Labs (New Jersey, USA).

DuMont Labs eventually sold its TV manufacturing division to Emerson Radio in 1958. The remainder of the company merged into Fairchild Camera in 1960. Fairchild later developed semiconductor microchips. Robert Noyce, founder of Intel, originally worked for DuMont Labs as an engineer. The DuMont Labs corporate history is a good read and can be found on the Wikipedia site here; *click here*.

Company History - Simulation

CAE's entry into flight simulation was a military contract from the Canadian government for six Lockheed F-104 Starfighter simulators. The F-104 program was the company's first experience with radar land mass simulation and the incorporation of a visual system, a motion system and a compact mission recorder. Within a five year span, 26 additional units were purchased by five other North Atlantic Treaty Organization (NATO) countries. With this experience CAE went on to build more military and commercial flight simulators.

By the time I joined in the mid 1980s, CAE developed commercial and military flight simulators, nuclear power plant simulators, SCADA control systems, ADATS training, Magnetic Anomaly Detectors (MAD) for Canadian maritime patrol aircraft and even the SHINMACS powerplant control system for Canada's new patrol frigate program. It was quite a diversified manufacturer by that time. What was amazing to me was that the Montreal plant, where most of this was built, only had about 2800 people. As business grew so did the number of new hires. There were also some acquisitions in the US. I recall a division of Hughes and Singer-Link or Singer-Miles were also acquired.

The level of responsibility given to new hires always amazed me. Here we brought in recent engineering graduates and put them to work on serious development projects with strict client timelines and yet we delivered a quality product in the end.

Before I left CAE, the company had started to build an extension to the plant to house Challenger business jet flight training. This was a bit of a departure from just manufacturing simulators, now the company also hosted the simulator and training facility on behalf of the client. This would soon open up the door to new business (training).

Traditionally, CAE would build flight simulators for airline customers but also for flight training schools, such a Flight Safety International. Smaller airlines who cannot afford (or it is not economically justified) their own simulator will go to the flight schools which own specific simulators and the instructors for their training needs.

Worldwide there are many such schools which conduct pilot training. So, in a classical business move of vertical integration, CAE started to buy out the flight schools. No only would they manufacture the simulators, but they would host them at their facilities and provide pilot training as well. This vastly expanded their business.

Several years after I left, CAE changed its logo. The original logo had the name CAE and to the right was a maple leaf with an overlaid globe. You can see it in the Oceanic Flight Data project logo below. This signified CAE as a Canadian company with a global reach. As CAE expanded into a global flight trainer and manufacturer, the maple leaf and globe was dropped in favor of a much simpler logo. Today it's difficult to find any trace of the original CAE logo from the time I worked there.

CAE would go on to develop many new innovations. Their corporate history can be reviewed here *click here*.

OSU S/W DEVELOPMENT

I joined the Operating System Utilities (OSU) group, where we developed support programs for various aspects of VAX/VMS and MPX (SEL/Gould/Encore) operating systems. These were the two dominant operating systems used at CAE in the 1980s for flight simulation. We had some Unix based systems, such as Silicon Graphics workstations, but I had not seen any used in commercial flight simulators. Since I had experience on Encore systems due to my University job exposure to the earlier Systems Engineering Laboratories (SEL) systems, I worked on applications running on SEL's MPX operating system.

Prior to joining CAE, the company had developed simulators using TI980 minicomputers (Tornado simulator) and PDP-11/55 computers (RCAF), but not sure if this ran RT-11 or RSTS. These were 16-bit systems. By the time I joined CAE we were using 32-bit systems for higher simulation fidelity.

Management felt that my blended hardware and software background would be a good fit for developing data transfer applications. My work was primarily building software for high-speed inter computer communications. Coding was done in FORTRAN 77 and ENCORE Assembler. CAE sent me to Florida for training on the MPX operating system internals. This was critical for understanding the MPX internal table structures supporting context switching and the logical to physical memory mapping mechanism.

SEL/GOULD/Encore Computers

The SEL computers were originally created by a small firm that specialized in building 32-bit computers meant for real-time process control and date acquisition. SEL was established in Fort Lauderdale, Florida in 1959 and designed a series of 16-bit and 24-bit computer architectures. The SEL-32 line (as in SEL-32/77) was a series of 32 bit minicomputers. These systems were widely used by US Government, Air Force and the even the NSA (code breaking?). These fast systems filled a series of government needs. I heard that even the IBM Federal Systems division was a SEL client who used these computers for some government contracts.

They featured memory mapping but not virtual memory. The 32-bit designs were continuously improved for speed through innovations such as ECL processor technology, Internal Processing Units (IPU), static RAM memory, shadow memory and reflective memory. SEL was later acquired by GOULD, a company most people are familiar with as a battery manufacturer. GOULD systems division was subsequently acquired by Encore Computer Corporation in 1989. My exposure to the MPX operating system was at my first job at Concordia University as a systems administrator. I had upgraded our SEL-32/77 computer's operating system from the Real Time Monitor (RTM) to the multi-user MPX operating system. I also wrote small programs on Writable Control Store (WCS) as demos for students along with a guide on how to program WCS, thereby familiarizing myself with the 32/77 architecture.

The SEL-32 architecture was similar to IBM's 360 system. Both were 32 bit systems. All controllers resided on the SELBus (transfer rate of 26.67 MBytes/second), similar to DEC's UNIBUS; it featured a unified bus architecture. The CPU, IPU, memory control and the input/output subsystem resided on the SELBus. One day, while reading up on IBM systems architecture for a university course, I noticed that IBM used the same channel controller architecture as the SEL systems. In fact, there was only a 1-bit difference between the SEL channel controller commands and those of IBM! Coincidence? I brought this up with one of the SEL managers. He explained that at one time RCA had built an IBM/360 clone. As SEL had hired RCA engineers, it's possible they brought the channel controller design with them.

The remainder of the article will make references to SEL and Encore but its really the same system, just under different owners.

Below are some of the projects I worked on. I should also mention that CAE had the practice of creating logo stickers for each project we undertook. These were highly coveted and traded amongst ourselves in the same manner kids would collect and swap hockey cards! The Oceanic Flight Data Processing (on the right) is an example of these. I'm not sure if they still create these, but it kept the art department busy and were wonderful to collect.

Fast I/O Disk Routines

My first project was to build a FORTRAN callable library of "Fast I/O" Disk Routines. This was a set of asynchronous I/O routines for reading and writing to disk drives on MPX. The previous set of routines, in my opinion, did not have a consistent, easy to use interface and honestly I was not thrilled about the documentation either. This new library was a clean start for fast disk data transfers. It featured a smaller, simpler, consistent callable subroutine with documented status and error codes. The nature of asynchronous I/O means that a program can initiate a data transfer and then continue its processing. Later on, it can query the status of the transfer to determine if it has completed.

Subsequently, I was tasked to migrate the routines to the VMS operating system. So, this became the standard library for disk I/O across both SEL and VAX simulator applications.

The effectiveness of these routines came to light when Nippon Airlines (Japan) complained that it took too long to start-up their simulator. They wanted the simulator to be up within 5 minutes of initiating the startup. Examining the loader application revealed that a lot of the data loading routines waited for the I/O to complete before moving on to the next steps. By changing the calls to fast I/O, allowed the loader to initiate the data load and move on to perform other load functions while the data loads in parallel. This brought the simulator load time to just under 5 minutes.

SD422 High Speed Data Interface

One of the first device drivers I was asked to write was for a High Speed Data (HSD) controller for the SEL computers. HSD controllers were used to move blocks of memory data in Direct Access Mode (DMA) over a parallel interface to external devices. The basis for the driver was an older HSD driver. The goal was to re-write the driver but with improvements for speed, such as double word alignment of instructions, strip the code to the bare minimum while maintaining reliability. A new callable subroutine library and user guide was created to support the HSD driver.

A CAE built SD422 controller card was connected to the back of the HSD and this provided a high speed serial interface between the simulator's host computer and other microcomputers. I had written test software to exercise the HSD and SD422 controller combination. It seemed to work well under test. The first time the driver was used was on a Boeing 737 simulator. I was at the CAE simulator bay to observe the data transfer stability and address any issues. It was nerve wracking! I worried the code would fail in a real-time environment with multiple HSDs running. Fortunately it worked flawlessly.

One of the fun aspects of working on flight simulators is that if you want to test your software, you book time on the simulator and take it for a flight (me above). For software testing you don't always need the motion system to be up, but you need everything else running. In testing I/O data transfers you need the visual system up and the flight simulation running so you can test the avionics system response. Over the years, I've flown, B747, MD11, MD80, B737, Fokker 100 and A320.

My favorite aircraft was the Boeing 747, thanks to its four engines it's a very responsive aircraft to the pilot controls. My least favorite was the MD11 (below); I found it slow to respond to power and steering inputs. As a side note, the CAE MD11 simulator in development "flew" the aircraft before a commercial MD11 flew. We experienced the MD11 flight characteristics first before any commercial pilot did. The MD-11 simulator cockpit is below. Swissair and FedEX were MD11 customers.

SEL/MPX Ethernet Driver

As the volume of data increased between the simulator mainframe and the micro controllers, the SD422 interface was challenged adapting to increased data volumes. At around this time Encore introduced an Ethernet controller for the SEL-32 systems. This controller operated at 10MBps and promised to support higher data throughout.

There was only one glitch, the MPX operating system's Ethernet driver was not designed for real-time work. It was too slow for the time critical simulation cycle time; all data had to be exchanged (transmitted and received) to the micro controllers within 30ms. Mainframe Ethernet controllers were needed to communicate with the motion system controller, the visual system and the micro controllers that drove the majority of the cockpit instruments. I attended an Encore user conference where a US Air Force representative described how they built a high speed Ethernet controller by coupling a custom built Ethernet controller board to a HSD, similarly to CAE's implementation approach for the SD422 serial controller.

Rather than following the same example, CAE decided that we should be using the Encore provided Ethernet controller but write our own fast Ethernet driver to operate it! Since I had written the HSD driver, I was given the task to write a fast Ethernet driver. I was allocated a dedicated Encore 32/67 computer with an Ethernet controller and the SEL Ethernet user manual as a starting point. There was no technical manual for the Ethernet controller, so a lot of experimentation was needed to get this running. One more thing; the driver had to be re-entrant, that means a single Ethernet driver must handle I/O for multiple Ethernet controllers.

So for several months my days were spent locked up in a lab room with the 32/67 developing the Ethernet driver. Development was frustrating. Any coding error in the drive would halt the operating system, resulting in a re-boot of MPX. A Fortran callable library and documentation for initiating data transfers to the Ethernet controller also had to be written. By the 4th month the driver started showing promise. It ran most of the time for several hours, other times it ran for minutes before crashing MPX. I could not determine what was causing the random crashes. It was very frustrating. The pressure to get the driver working was intense as there was already a new flight simulator project requiring the Ethernet connectivity. Ethernet controllers had already been ordered from Encore for the simulator. There had to be a better way to make a living!

We didn't get a lot of support from Encore for helping troubleshoot issues. I suspected a third party provider had actually developed their driver. Their position was that the driver delivered with the controller was the driver to be used on MPX.

Every time MPX crashed I would examine the memory dump to see what caused the crash. It was always a corruption of memory within various areas of MPX; the computer was attempting to execute an instruction that was not an instruction. By chance, one of the memory dumps showed an illegal instruction that oddly looked like a controller's Program Status Doubleword (PSD). This was a key finding. It turned out that you had to program the location of where to put the PSD otherwise it would take a random location in memory at startup. The PSD location was then programmed to be at the top of driver space. Henceforth, the driver was stable. Further testing on multiple Ethernet controllers validated the driver was re-entrant.

So, after five months of development, a stable fast Ethernet driver and supporting callable routine library was ready. This development allowed for commercial Encore Ethernet controllers to be used on flight simulators. All data required to be sent from the simulation mainframe to the micro-controllers could be delivered within a 30ms frame time.

When I designed the driver, I also built telemetry into the driver. As the driver was running I could issue calls to check how many successful packets went in or out of the controller and collisions experienced. My team leader was not supportive of this approach. He felt that the telemetry added additional instructions to the driver and caused more writes to memory than was warranted. I understood his position, the driver could be even faster without the telemetry, but this being a new driver and controller, I needed the ability to check on the health of the combination in real-time. Writes to memory are more expensive than reads because of cache coherency and write-back to memory. This driver would be widely used. I persisted and left the telemetry in place knowing that any future problems experienced with Ethernet transfers could be blamed on the driver. I needed the telemetry to monitor the health of the driver. In future, this would come to be a big time saver.

However, as we started using the Ethernet setup on a simulator, the communications would infrequently freeze. Through extensive driver testing and observing the telemetry data, I was confident this was not a software issue.

So, in the coldest Quebec month of January, an Encore engineer and his manager came up from sunny Florida to investigate the controller issue. For several nights we ran load tests on the Ethernet controller. The Florida team attached a logic analyzer to various points on the controller. Eventually the controller halted and after some investigation, a race condition was found in the controller that would cause it to hang. The Encore team headed back to Florida with the information and subsequent Ethernet controllers were issued with new firmware. I wondered if the driver was responsible for stressing the controller to run beyond its design limits.

No further issues came ever came up with the controller or the driver. It was quite successful. On one simulator, the driver managed four Ethernet controllers. I attended industry conferences thereafter but we never publicized that CAE had the capability to do fast I/O with the commercial Encore Ethernet controllers. When at the conference the USAF demonstrated their fast Ethernet solution utilizing custom hardware, my manager smiled knowing that CAE had the better solution. This was one of the most satisfying and stressful projects I had at CAE.

Air India - Inter Systems Communication

This was a custom MPX communication system using HSDs to connect computers. It was effectively a parallel system interface to move data at high speed between systems. The client needed the ability to examine disk directories and files and move them from one Encore computer to another. The two computers were on separate floors so there was a bit of cabling distance and a risk of communications failure therein. One requirement was that if the computers lost communication, they had to automatically re-synchronize and resume the communication flawlessly. If communication failed, each computer would attempt to establish communication with the other.

It was impossible to determine which computer dropped the data transfer, so both would attempt to re-sync with each other after a failure. The approach I came up with was assigning each computer a single digit node number. The node number determined the communication retry rate for synchronization. Because each computer would try to sync each other at different time intervals, it avoided the issue of the sync retries occurring at the same time on each system and the re-connection attempt going on endlessly. The approach worked fine.

A simple text interface and help menu was created for the application. Each computer could query and move files from/to the next computer. The application was delivered to the client. No other client used this application as the client had fully funded its development.

KLM - Inertial Navigation Computer Loader

I remember this application because it was so different from what we normally worked on in the OSU group. At CAE when we were given a project, as a developer, we had a lot of latitude on how we implemented the solution. The project was to read a file from disk on the SEL system and over a serial interface download it to an avionics black box (literally it was black), an inertial navigation computer used on a Boeing 747-200. To validate the software download was successful, you would have to read back the black box contents and compare them with the downloaded file. If they matched, then there was no corruption of the data. The serial interface (RS232) to the box was slow (9600 baud possibly). I recall that high baud rates would cause errors as the box could not respond quickly enough to take the next character.

After we validated the download was successful I would take the black box with me in the rental car and drive it down the road from KLM's simulator centre to an avionics building where a further test was made to check the integrity of the download. This box was heavy and was about 3 feet long. I couldn't believe KLM let us bounce around the facility's cobblestone roads in our car with a $100K black box in the rear seat. We tried the test download a couple of times to be sure it worked.

The code was developed at CAE, but we could not test it until we arrived at KLM, as we didn't have the avionics unit in Montreal to test. At the time most of our development terminals were DEC VT220s, which had a base graphical character capability. So, having free reign of the design I decided it was time to build a graphical interface for the loader using the VT's graphics character capabilities. At CAE the software was tested best I could. I went off to KLM with some other folks for a simulator upgrade and in the process we tested the software on the avionics unit. I tested the loader several times, but randomly I occasionally noticed a difference in the downloaded data as compared to the uploaded data. I didn't know if the data was corrupted in the core memory of the box,during the download or upload process. The error rate was infrequent, so the client just had to be sure that if there was a discrepancy, to run the loader again until it loaded successfully.

All worked fine until the client ran the data loader with the simulator running. With the simulation running, there was very little remaining CPU capacity for background tasks, such as the loader. The result; the graphics interface I so proudly built, slowed to a crawl, it was barely usable. I also worried about the data integrity going to the box if there was so little CPU capacity to manage the serial download.

Lesson learned, never build a fancy interface when there is no CPU capacity to manage the graphics. I never used that graphics library again. The client was informed that it was best to use the loader while the simulator was not in use. Another day, another learning!

NASA - Crew Station Research and Development Facility (CSRDF)

This project stood out for me because it was a very difficult one, requiring many nights, weekends and a lost holiday to get this working. This was a research project driven by NASA and sponsored for the United States Department of the Army. It was to evaluate different visual and audio interfaces for the Light Helicopter Experiment (LHX) cockpit. In effect test new ways for the aircraft to communicate with the human operators. The architecture was based on a large VAX/VMS mainframe with Ethernet controllers to various components, such as the visual system which provided the images for CAE's proprietary Helmet Mounted Display (HMD). A helmet that was also used on other virtual reality simulators.

I later learned from my manager that CAE was the only company that took on the project, although it was offered to other firms, including our US competitors. However, CAE was paid on a time and materials basis, not fixed cost, so that made it more attractive as a project notwithstanding the benefits to the firm from improvements to the HMD and possible new business from the defense sector.

One of the first challenges of the project was thinking that a 10MBit Ethernet controller could actually deliver 10MBits of data. It was overestimated how much data could be delivered. We didn't have a lot of experience with DEC VAX Ethernet controllers just yet. More controllers had to be added to compensate for the lack of throughout capacity.

Another unexpected project delay was coming in one day and finding out that someone had removed the circuit boards from the VAX mainframe. We suspected they were re-sold on the secondary market. The computer could not run until new boards were received days later.

In the meantime we had some folks from NASA coming and going to see the progress on the overall CSRDF. We had a wonderful lady from NASA that would take orders for NASA patches and bring them to us next time she was at CAE.

Because I had experience writing the callable Ethernet library for MPX used to connect the SEL mainframe to the visual system, I was assigned to integrate the visual system to VAX/VMS. Just one obstacle, I was not familiar with VAX/VMS, so a developer from another team with VMS experience, Julian Berdych, was assigned to the effort.

Together we worked in the evenings hours and weekends on developing the driver code to execute data transfers between the VAX and a visual system. We even worked through the Easter holiday to make progress. This being OS level driver development, there were many times whereby we crashed VMS and then had to spend 15 minutes re-booting the VAX. It was frustrating and time consuming. Julian understood the VMS internals and I noticed patterns of bad code behaviour that kept occurring. Julian would comment that if we were at IBM, we would be fired by now! I can't recall how long it took to get the driver running successfully, but we eventually got it running properly without crashing VMS.

During the Easter break there was a mini revolt by the developers who had been working through weekends on various components of the project. They wanted time off with their families for the holiday. The project manager was not supportive of that and wanted everyone in. So, a quick call to our managers "convinced" us to work through Easter. There was a lot of complaining from staff and their families.

Back to our visual driver, there was one small glitch in production; if the communication terminated abnormally between the VAX and visual system, it would take 15 seconds for the software to flag the malfunction. That means the pilot would notice the visual failure before the system did. We attributed the delay to the way VMS worked. I was surprised that VMS being a multi-user and batch oriented OS, not designed for real-time, was a successfully used for flight simulation.

Training was subsequently delivered in-house the the NASA folks; they would be supporting the application thereafter. Overall, this was a very frustrating experience which at times we felt we could not overcome the challenges. Drivers, no matter what operating system, are not easy to develop or debug.

The project was a great success for the Army and CAE. The project manager received a gold medal from NASA for his leadership. The rest of the team received a very nice Group Achievement Award signed by NASA's Administrator.

GED - Tools Marketing/Sales for MPX Utilities

At some point, the OSU group had developed enough applications that facilitated software development on the MPX OS. Encore's MPX lacked a lot of the niceties, as compared to VMS which was a much better S/W development environment. For example, command line recall, a full screen editor, and others that the OSU group developed to make MPX a more usable environment.

So the idea was floated by my manager, why don't we sell the applications as a productivity bundle for the MPX environment. This would provide developers at other companies with a much richer MPX experience.

I'm not sure why I was picked as I don't have the personality for sales, but I was willing to try. It was decided we would attend several Encore client conferences to market and sell the applications. The package was named the "GED Utilities", for some reason this was associated with a mythical wizard. So we had the art department come up with a poster of a wizard with a magic wand. Recently, I found a Wikipedia entry describing that "Ged is the true name of a fictional character in Ursula K. Le Guin's Earthsea realm. He is introduced in A Wizard of Earthsea, and plays both main and supporting roles in the subsequent Earthsea novels." This was going to be the backdrop to our booth at these conferences. Not sure who, but someone was a fan of these novels. We took that silly poster to each conference. In hindsight, it really looked amateurish.

We attended several conferences to market our product. Although the package was not expensive, it was difficult to make a sale. One problem being that Encore's customers are large companies and government organizations. Their budgets work on an annual cycle. If anyone was serious about purchasing the package and it was not a planned purchase in this year's budget, it would have to be a business case for the next year. We often heard the response that it was not in their budget.

Nevertheless, I spent a couple of hours a week at CAE dedicated to marketing the package. By this time I had a list of contacts of most of Encore's clients. I cold called each one in my attempt to make a sale. The same budget issues kept coming up.

One interesting call was to the National Security Agency (NSA) in the US. I knew they were a large Encore client. However, when I called reception to forward my call to my NSA contact, they asked me if I was calling from outside the US. I said I did and they explained that they could not take any calls from outside the US. I though it was odd, but there must have been a security reason for it.

Another interesting experience was at one of the Encore conferences. We were approached by the Encore salesman that indicated there was an airline customer who was going to be purchasing a simulator, but could steer the deal in CAE's direction if we offered to take him and his wife up to Canada on a skiing week. I had heard that these junkets were the norm in some industries (pharmaceuticals) but had never actually experienced this. I took this to my manager who upon hearing of the proposal said "that's not how we do business at CAE!", and that was the end of that.

My manager stipulated that if we didn't sell by the end of the conference, this would be the end of our GED marketing/sales effort. In the end, I never sold a single copy of the GED package. Back in Montreal, my manager made a sale to the transit authority which was using Encore fault-tolerant computers to run the Montreal Metro system. This was the only GED sales ever made.

NOTABLE TRIPS

Over the years I had several trips to the Unites States (US) and Europe for simulator updates. Some of the trips that I recall best were those to interesting locations, others were the technical nature of the project and others were simply fun. The most interesting projects were the military ones as they were so different and more complex than the commercial simulators.

Deutsche Luftwaffe - Panavia Tornado, Stolberg, Germany

This trip was one of the easiest ones I had. It also was a great opportunity to explore the German countryside. CAE has a small facility in the city of Stolberg. The staff at Stolberg told me that CAE used to assemble personal computers at this location. There was also a Tornado simulator used for nap of the earth low level flight training. The wonderful thing about this simulator is that it used two CAE helmet mounted displays, one for the weapons operator and one for the pilot. The images for the pilots were transmitted directly to the helmet instead of having the images projected onto a radome, as other simulators. Positional indicators atop each helmet indicated to the visual system where the pilot was looking and therefore what image to display. Because of visual system capacity limitations, it would display, for example the landscape area that the pilot was looking at.

I was sent there to develop a data transfer routine. The need was to move data quickly from the Encore simulation computer to another system. The routine performed the logical to physical memory mapping, programmed the channel controller with the physical memory locations and then initiated the transfer. Unfortunately, I never got to fly the Tornado myself, as other CAE engineers had that pleasure.

So, CAE sent me to Stolberg and as we needed a High Speed Device (HSD) on site quickly for the fast I/O, I was asked to take the HSD controller with me. It was a circuit board measuring about 24 inches by 30 inches in a cardboard box.

When I landed in Germany, the nice customs officer asked me what I was carrying. So I mentioned that I was working for CAE on a project and we needed the HSD on site quickly to support a Luftwaffe project. Next question; "do you have the commercial paperwork for the device?". I didn't know we needed any paperwork and CAE hadn't provided any either. I could see this was going to be a problem. Could customs confiscate the HSD? So, the officer understanding my conundrum looked at me, eye to eye and said "You are bringing this device into Germany for your own personal use, yes?", of course I replied "Yes" and I and the HSD were free to go. He really gave me a pass; nice guy!

Germany had, or still has, labor laws whereby you can only work 37 or 38 hours per week. The rationale being that if you have to work more than these hours, then it means you are short staffed and should hire additional help - it's a very social democratic approach to employment. Anyone who has worked in IT knows that project time is always elastic; it takes longer than we think to achieve anything. So we would work during the day, go out for dinner, wait for the janitor to leave and then go back to the site for a few more hours of work. I didn't see a lot of full time staff at this location, it was a small operation; maybe larger today.

I was kept around for about a week in case anything else was needed. The CAE site manager was great. He made sure that everyone had their own car. In my case I had an Audi A4 which, on the weekend, I drove on the Autobhan and explore the Rhine region. I was sorry to leave Germany as it was so culturally rich. There was so much more to see and experience. I ended up going back on vacation.

RCAF - CF18 Bagotville, Quebec

This trip was nothing complicated, it was a routine upgrade of a CF-18 simulator Encore computer. The reason for the upgrade was to give sufficient processing capacity to train pilots on new threats; as in certain models of ground to air missiles. What stood out to me was the systems preparation work and the harsh Bagotville location in northern Quebec. Before heading to Bagotville, the new SEL computer was tested at CAE.

Because of the classified nature of the simulator, the computer was housed in a custom built Faraday cage at CAE. Once inside you could work on the MPX operating system configuration without any interruptions. I often carried a pager, should anyone need me urgently on site. Inside the Faraday cage, no signals could get in or out; including pager signals. The simulator's four disk drives were labeled with a red and white sticker with the word: SECRET. A security guard would occasionally come by and check who was in the cage. A SECRETs clearance was needed to work on this project.

The disks could not be shipped to the simulator site by normal carrier but had to be hand carried by someone on a commercial flight due to the secret nature of the disk contents. The MPX configuration was straightforward as I had performed several system upgrades by now.

After the computer was shipped to Bagotville, I was sent to ensure there were no issues with integrating it into the current simulator hardware. I arrived in Bagotville in early January. It was bitterly cold! I arrived at the car rental counter and the attendant looked at my driver's license and noted that it was my birthday so I got a free upgrade; it was a large American car! Really nice people. In hindsight it was a good thing as there was about a foot of snow on the roads in town.

Other than the RCAF air base, Bagotville is also a mining town. Former Alcan (now Rio Grande) had a mine there and between the air base and mining those were the major employers. I found people were super friendly. For a small town in the North, people dressed exceptionally well. I was told this was the Quebec culture.

Food was great. It's the only place where I've ordered a Pizza and people will fold the pizza in half and eat it folded over. I was told it was easier to eat it that way by hand.

It was so cold that the car windows froze in place; neither up or down. Two of the four doors froze in place. Fortunately the driver's door was spared. The simulation integration went well; no snags. After the third day I eagerly booked my trip back to Montreal.

US Air Force - F-16 Virtual Reality Simulator

My participation on this project was small compared to the technical challenges solved by other engineers on this unique simulator. The project site was in Glendale Arizona at Luke Air Force base where F-16 pilots are trained. The reason this location was chosen for a training base is that there skies are sunny and cloudless 365 days a year! Perfect clear skies for pilot training.

This project was an F-16 Falcon flight simulator (no motion system), with one significant difference; it relied on the HMD to display the visuals. The simulator's cockpit rested fully in the middle of the lab. However, once the test pilot sat in the cockpit, and put on the HMD helmet, they would find themselves on an airfield sitting in an F-16 cockpit. With the helmet on you could see the aircraft fully, the wings, nose, the runway, you could look behind you and see the fighter's tail and surrounding scenery. The imagery running this display was projected to the HMD over fiber-optic cable by two General Electric (GE) image generators; one for each eye. This setup gave the pilot a stereoscopic view of his surroundings. I recall that each image generator were a series of 19 inch racks with custom hardware (many TRW multiplier chips) stretching our for about 10 feet. As with the Tornado simulator, this was virtual reality setup!

However, there were some limitations. The image generator could not in real-time generate the full image in detail for the points where the pilot was looking at. The solution was to use the HMD head tracking, to see where the pilot's head was pointing. For example if the pilot was looking left, there was no reason for generating the images to the right of his field of vision. The data on which way the pilot's head is turned is fed back to the mainframe which passes the data back to the visual system. So this approach narrowed the processing required to generate the image for each eye by narrowing the amount of visual landscape to display.

There was still one more refinement. Although from the position LEDs atop the helmet, you could determine by triangulation the position of the pilot's head, you could still not tell what the pilot's eyes was looking at. For example, you can turn your head to the left but your eyes gaze to the right, the visual system would still think you are staring to the left.

The solution was to install an eye tracker that would send back the information as to where the pilot's eyes are looking at. This is accomplished by bouncing a light beam off the eye (retina?) and reading the positional location of where the eye is looking. The information is fed back to the simulation mainframe which in turn provides the information the to the visual computers to generate the image the pilot sees in higher detail where the pilot's eyes are focused on. Peripheral vision can be generated at a lower resolution but all the processing effort for the visual system would be focused on what the pilot is staring at. Of course, all this needs to happen immediately in real-time. If the pilot swivels their head and eyes, the visual system has to follow with the detailed image.

F-16 Virtual Simulator

This is where I became involved. A technician and myself flew down to Arizona to install an SD422/HSD combination interface that would gather the data from the eye tracker and transmit it to the mainframe. I made the changes to MPX to recognize the controller, ran the tests and all worked fine. Software was updated to call the data routines for the SD422 and all worked as expected.

There is one more nuance to the visual system. Although the pilot's scenery is virtual, when the pilot stares down at the cockpit instruments, the actual instruments and controls are displayed. In other words, the visual system switches off the image when the pilot stares at or uses any of the cockpit controls. In the diagram, this is the area below the synthetic video area. Anything within the synthetic video area, and around it, is an image generated by the visual system. For example, the pilot will see the aircraft's nose if looking above the instrument panel, as this is an area that the visual system kicks in to display when the pilot looks in that direction.

On-site was an Encore technician contracted by the Air Force to look after any issues with the 32/97 mainframe. When our technician showed up, we were ready to power off the mainframe and install the hardware, but we were stopped. By contract we couldn't touch the computer because if we messed anything on the hardware side, it was Encore's responsibility to fix. So our technician, stood by while the Encore technician installed the hardware. Installation of hardware on the SEL mainframes is tricky as the backplane is an old-school carry-over design. The HSD controller slides through the front of the computer and its board contacts connect well with the backplane female connectors. The SD422 which goes behind the backplane connects through a messy pin configuration. That is, the SD422 connections are female while the computer backplane is a series of male pins. The problem, is if you aren't careful, it's easy to bend a backplane male pin when connecting the SD422 or any other card on that backplane.

Sure enough the Encore technician bent a pin while inserting the SD422 controller. Bending the pin is a problem because when you straighten that pin back, it could form a weak connection (metal fatigue) or it could touch another pin and short some backplane data bit, or worse it can fall off completely and make that circuit slot unusable.

There was a lot of cursing and sweating by the Encore technician. The HSD was moved to another slot and our technician installed the SD422 controller as they had more practice from doing this on several CAE simulators.

From there on, all worked fine. We had a British pilot try out the simulator for several hours. One complaint I heard from the engineers was that the HMD caused eye fatigue after a couple of hours on the simulator. A CAE engineer also mentioned that some pilots experienced vertigo.

We spent several days on-site in case something else should be needed. The base was an interesting environment as compared to working at a commercial flight training facility. Our lab was an isolated building surrounded by two barbed wire zones. An armed guard would also occasionally be seen patrolling the area. So to get into the lab, you used a magnetic card to open the first zone which was behind a barbed wire fence. Once inside, you used the same card to open a gate to a second barbed wire tall fence. If you didn't have the proper authorization, you would be stranded in the no-man's zone between the two fences. Then you would have some explaining to do! Once you go through the two security fences it was a short walk to the secure lab building.

We would eat at the officer's mess every day as the food was quite good. One day we had a visit from the Thunderbirds Air Force aerobatic team. They flew F-16s decorated in the white, red and blue of the American flag. They sat next to us in the officer's mess for lunch! Super excited to have worked on this project. Was a great time.

Scandanavian Airlines (SAS) - George Moody Simulator Upgrade

This project was unique because SAS asked CAE to upgrade the motion system and software on a SAAB 340 simulator that was not built by CAE, but by George Moody Inc.! George Moody also used the SEL series of computers on their flight simulators and this is how I came to be involved with this project.

The CAE team included a project manager, a summer intern software developer from Waterloo University who was familiar with the motion system software (he's in the picture below), a technician for any interfacing needs and myself for MPX updates, configuration and S/W assistance. There was also a crew of mechanics sent to install CAE's hydraulic motion system. We stayed in Kista, Sweeden, at the Memory Hotel (hard to forget that name). However, that didn't last long. Because of the noise created by the rowdy mechanics and complaints from other guests we were all kicked out and had to find a new place to stay. The unionized mechanics were party lizards, and we kept our distance from them.

I arrived on site at SAS to find that the simulator looked like it was built in someone's garage. Most instrument boards seemed to be hand-wired. The cockpit's background air traffic sounds were a tape recorder! Overall, this did not seem to be a high volume simulator manufacturer. It's as if the whole thing was hand-built. One item that perplexed us was how they configured the simulation software. The computer was a SEL-32/77 with an IPU and another CPU in a separate chassis. I could not figure out how they loaded the second CPU. It seemed an executable was loaded directly into memory and then executed by the second CPU. It was well designed and I admire whoever configured that software loader architecture.

Most of the subsequent work was technical. The PM left us alone and I was grateful for that since we managed the upgrade amongst ourselves. The intern and myself managed most of the software integration. The motion system software was loaded on the SEL and compiled. I updated MPX to include the HSD and SD422 interface.

When the software was run it consumed all the spare CPU capacity and more. There was no way this configuration was going to run the CAE motion system. Because there was no spare CPU capacity when the simulator ran, it was impossible to shut down the simulation from a terminal as there was no spare background capacity. Using the SEL's console switch register we were able to enable or disable the motion system software. By checking if a console bit was on or off, the motion software could be bypassed or executed. By setting the register bit on, signaled the motion system software to exit and enabled us to shut down the simulation as needed.

We ordered a floating point processor card and more memory for the SEL-32/77 from CAE. This was the same computer model I managed at Concordia University. With the new hardware the simulator finally worked. We were on-site at SAS for a couple of weeks.

The SAS system administrator asked us if we could add an additional disk drive to the system. I configured MPX for the additional storage. We were rewarded with SAS sweatshirts from their flight shop. I went back to the shop and bought a SAS polo shirt for my wife. For the longest time people thought she was a pilot! It was a great trip as we got time to explore Sweden on weekends. The CAE mechanics went on the party boat to Finland, so they could get drunk on the cheap. I had a nice Volvo car and instead drove around Stockholm, Vaxholm fortress and took a cruise on the Swedish archipelago. We met some wonderful people while working at SAS. It was a great trip!

Air Canada - Airbus 320 Simulator Problems

This trip was a short trip from Montreal to Air Canada's flight training facility located outside Toronto's Pearson Airport. An Airbus A320 simulator was recently delivered from CAE. This simulator was based on the Encore series of computers with Ethernet interfaces to the various micro controllers.

Once pilot training started, there was a problem. The cockpit instruments were not displaying properly. The analog style dials displayed on the glass cockpit, would skip instead of rotating smoothly. Response to inputs, such as steering inputs were delayed. The most obvious issue was the skipping dials on the glass cockpit. The first thought was that data from the simulator mainframe to the micro processors over Ethernet were being dropped. Of course, the blame fell on the Ethernet driver. This is where the driver telemetry came in handy. Looking at the number of packets successfully transmitted and number of collisions detected, revealed that all was well with the controller.

CAE sent a couple engineers to Air Canada to try to resolve the issue. Two weeks passed and there was no idea of what could be causing the issue. The client was getting impatient as pilot training on the A320 was held up. As the premise was that data was being dropped somewhere in the communications, CAE decided that I should go to Toronto for a look.

The first thing that hit me when I walked into Air Canada's simulator facility was how warm it was compared to other data centers I'd been at. For example, at Northwest Airlines (St. Paul, Minnesota) the simulator computer room must have been in the low 60s Fahrenheit as we had to wear winter coats to work there. It was the coldest simulator facility that I'd ever been at. Similarly, in the warm and humid Brazilian jungle, Varig (Brazilian airline) had its flight training facility. I was told that in the evenings, snakes and lizards would make it through cracks in the facility's door. As the simulation facility was cold, as it should be, the critters would come to a stop and just lie there; too cold to move. The janitor would scoop them up in the morning and throw the back into the jungle!

Yet, here technicians sat around chatting comfortably with the room air temperature in the low 70s. It struck me as odd; computer rooms were normally cool and not a comfortable environment for people, but I didn't think much else about it at the time.

Examining the Ethernet controller statistics indicated that data was being sent out from the mainframe without any issues. Following the data to the micro controllers indicated that data was received at that entry point. But wait, while watching the flashing data LEDs at the micro controllers, the LEDs went dark, and then back on again shortly thereafter. It seemed the micro controller processor just went off-line and back again. So we focused on the micro controllers. The micro controller processors were the interface between the input/output to/from cockpit instruments and the simulation mainframe.

CAE had shipped a new modern looking cabinet design that housed the micro controllers. The inside temperature was rated to be good up to 85 degrees Fahrenheit. However, the ambient air temperature was within spec but the internal cabinet temperature was much higher, indicating that hot spots were created within the cabinet. These hot spots caused the micro controller processor board to overheat and shut down. As soon as it had cooled off, it would come back on-line and the on/off cycle would repeat, resulting in the cockpit instrument stepping.

I requested the computer room temperature to be dropped to 65F. The technicians were moved out of the room. Once the room was at temperature the simulator was loaded. The stepping instrumentation issues were no more. Some folks didn't believe this was the issue, they were convinced the micro controllers were faulty. So, we repeated this two more times, raise the temperature, load the simulator and see the failures. Lower the temperatures, load the simulator and see no issues.

Next, we had an Air Canada pilot come in and take the simulator through its paces. We tested several scenarios, landing, take-off, and air collision avoidance. The latter was a scenario that visibly shook the pilot. That scenario consisted of another aircraft heading on a collision course with the A320. The pilot had to perform an avoidance maneuver. The pilot gave the simulator a pass. All was good again and back to Montreal for me.

Issues are not always purely technical failures; this one was environmental. The telemetry built into the Ethernet driver convinced me it was not at fault and encouraged diagnosis of the downstream systems instead. CAE still had to do some explaining about the cabinet hot spots, but in the meantime, pilot training resumed with a cooler computer room.

Other Trips and Places

There were trips to many other places that were exciting. The nature of the work wasn't so difficult by this time but required you to remain on-site for a week, or more, to ensure all interfaces worked well and the mainframe OS was stable. Among my favorite places were trips to KLM (Holland) and Swissair (Switzerland).

At KLM I was on-site with a CAE technician doing a software upgrade of some sorts. We got a call from CAE about an HSD problem with a Citation simulator in the northern part of Holland; a training school. The Prince (yes they have a monarchy) was scheduled for flight training on the simulator the following week and could we quickly get up there, fix the problem and then continue our work back at KLM? This would have been a four hour drive there, an overnight stay for sure and another four hours back. In effect a lost work day at KLM, as a minimum.

Our KLM folks were not thrilled about losing time on the upgrade, but it was the Prince after all. So, KLM offered us a solution to get us in and out faster; "Why don't you take the Cessna up to the school?"! The side door of the training facility opened to reveal a parked Cessna (looked like a Skymaster) in KLM colors. We had to admit that none of us had a pilot's license! Was a shame. Our CAE technician was able to solve the HSD problem over the phone and all was good again.

There were several more trips to KLM for various projects. For one project lasting a couple of weeks we stayed at the Grand Hotel Krasnapolsky in Amsterdam. That was a really nice hotel with wonderful breakfasts. Every day we would drive to Schipol where KLM had their training facility close by. I ended up there for so long that I eventually flew my wife there; the hotel room was already paid for after all. She flew into Belgium, we drove there to pick her up. We went back to Belgium a few times to explore the country. When in Europe, every other country is close by. Some people even drove to France from Holland.

At one time, we had a trip to KLM but most hotels in Amsterdam were occupied. So I stayed at the Hotel De L'Europe which at the time was one of the more expensive hotels in the city. I kept getting calls from CAE about the cost, but they couldn't find anything else. It was a nice hotel, right on the canal. If you left your shoes outside the door, the next morning they would be polished! Issues with accommodations and the cost used to be an issue. We often overstayed our trips. Payment from CAE was often slow to cover the hotel costs. In Zurich, I had the hotel manager meet with me a couple of times because he was concerned about the high cost of my stay. Eventually CAE settled the bill and I was allowed to stay. This was before anyone was issued American Express cards; it still felt like a small company.

Trips to Swissair were equally fun. They were not complex or demanding. However, I had the weekends and a car to myself. So I traveled as much as I could on weekends. Switzerland is expensive. I was in St. Moritz one day and was ready for lunch. Looking at the restaurant prices, I settled for a croissant at the local bakery instead. One benefit from working at Swissair is that (as with KLM) you have access to the company's flight shop. This is where their staff can buy goods at a discount; no outsiders please! Every time I would go I would bring back boxes of Swiss chocolates; literally boxes and boxes. This was always welcome at work and at home!

I know that on one trip to Swissair I ruined someone's vacation. CAE used to get a number of service tickets from the airline they were developing the simulator for. This made it more affordable for CAE to get these rather than pay full fare for a business ticket whenever someone had to travel to the client. So, as with others, we traveled on service tickets to Swissair. Service tickets are also used by the airline employees and their families to travel basically free if there are seats available. I showed up at the airport Swissair counter on my scheduled flight day and presented my ticket. The attendant said there was no space left, other people were already traveling on a service ticket. I had to explain that I was on business and was scheduled to be on site at Swissair to work. I had a confirmed ticket! So, she picked up the phone and from the gist of the conversation, a family was bumped off the flight.

I ended up in business class, where I was spoiled with great food and a couple of champagne bottles. I landed in Zurich with quite a headache and dizziness from drinking. The effects of altitude on alcohol are true. I showed up at the site the next morning with bags under my eyes and an feeling ill. To this day I never have more than one drink on a flight; was a great lesson.

Whie in Switzerland, I traveled around quite a bit; Lucerne, Bern, Mount Pilatus, Montreux; it was one of the benefits of being in-country for longer than planned. Geneva was nice to visit and would recommend it as well. I had a very relaxing lunch at the Ritz Carleton Hotel de la Paix with a nice view of the city. The cafeteria food at Swissair was really good! Nice warm meals that were very reasonable. You could eat really well there. They even served wine and beer at lunch, something you would never see in a Canadian workplace. It put CAE's cafeteria to shame. At KLM we would often get the same food that the airline passengers ate. It came wrapped in an aluminum foil box; it wasn't too bad. Often we could get Indonesian dishes, but Swissair had the best food and nicest cafeteria.

PEOPLE

I found the people at CAE were quite professional. It was an engineering organization; folks focused on their work, were eager to help each other out and made for a great culture. There was very little visible politics. Unlike some other large organizations I worked for, there was very little political games being played. Sure we had people on the team jockeying for promotions, but that was expected to happen. Not everyone got to advance, that's just natural. Some folks weren't happy and others were just happy to be working in such a technically challenging and fun environment. I worked there for many years, with no pension, just for the sheer pleasure of the work.

There was one trend that I observed while at CAE, was that on a personal basis, the work took a toll on people's personal lives. The constant travel away from home for weeks and sometimes months was an impediment for a stable family life. The result was that the divorce rate was high. Those who thrived were those with few personal responsibilities and could fly off to distant destinations at the whim of the firm. As an example, I was sent to Holland for a simulator upgrade, meant to last a week. But since I was already in Europe, could I travel to Germany for a problem there. After Germany there was an upgrade at Swissair, could I go to Switzerland after Germany and work there. One week turned into one month. I was there longer than expected, my passport expired while in Germany. Since I was going to Switzerland I could get my passport renewed in Bern. As I was driving between countries, someone suggested that when passing through border checkpoints to say the minimum and look stern so they wouldn't ask for the passport. Fortunately, no one asked!

On one trip I left so quickly to another site that I didn't have time to collect my clean underwear from the hotel laundry. One of my co-workers later picked them up from the hotel, flew them back to Montreal where I found them on my desk, nice and starched!

One day, I found an airline ticket slipped under my hotel door; could I go to India for a couple of weeks. I had to say no, and it was difficult to say no to my manager. They had to send someone in my place who ended up spending a month on site. It was not a good conversation.

I imagine in today's world of global connectivity, the need to be on-site constantly is lessened and people can actually go home to their families after work, most of the time. Today, most systems work can be completed using a secure Internet connection to a remote simulator client site.

Some of the folks I worked with, and still remember their names after all these years, are listed below.

• Sorin Axelrad - was the OSU Group manager. A brilliant mind but a very demanding and often difficult manager, also a heavy smoker. This was back in the days when you could smoke at work. I went on a few trips with Sorin to Encore user group conferences in San Diego, California and Fort Lauderdale, Florida. Wile in San Diego we even made it into Tijuana, Mexico for a quick shopping trip! Glad that Sorin never made an issue of me renting a sailboat for a quick sail on San Diego Bay during the conference.
• David Garmaise - led the DMC (Digital Microprocessor Controller) team of engineers that developed code for interfacing custom I/O cards with aircraft instruments. David had a wonderful sense of humor. At one time he had to hire new staff, but his group were all non-smokers, the last thing he wanted was to hire a smoker. So we discussed how do we go about ensuring we don't get stuck with a smoker. The winning idea was to offer cigarettes to candidates at the interview. If they took one, they were out! Not sure if he ever went through with it, but he really didn't want a smoker on the team.
• Duc Bui - replaced David Garmaise when David left CAE for work in Ottawa. Good leader, very approachable and well liked by his team. Most of our team attended his wedding.
• Patrice Meloche - developer. Really nice, considerate guy. Someone you could count on to get you out of a jam.
• Louis Lamarche - OSU Team Lead.
• Dieter Funke - MPX developer. We did a lot of work together on the SEL platforms.
• Steve Mohns - software developer. As a team, we sometimes played Air Combat on a series of networked Silicon Graphics (SGI) workstations after hours (until we were kicked out). Somehow Steve always won. It was so annoying, he seemed to defy the laws of gravity.
• Steve Potter - was an MPX developer on our team. My first introduction to Steve was his question "Do you like beer?". I said I enjoyed a Molson once in a while, he replied in his notable English accent; that was not beer! Did I ever try an ale? Steve was a good developer and I learned a lot of the SD422 controller from him. In fact I took over the development from him so he could work on another project. He had a strong personality. He had a difference of opinion with management on how some software application he was working on should be designed. He stood his ground, despite objections from management. He eventually left CAE. A bit of a knowledge loss for the firm.
• Julian Berdych - a very bright engineer, formerly an IBMer, who was assigned to help me with building a VMS visual driver. Julian was a tremendous partner with great VMS knowledge. Could not have done it without his assistance.
• Harry Laudie - a very talented, intelligent, software developer with a wonderful sense of humor. Educated as a physicist he was also an avid investor. He would often ask me what stocks I had bought that month so that he could avoid them! However, he was always ready to share investing tips. The gold mine tip his wife heard about at the country club, however was a waste of my money! I regret it to this day!

  Harry stood out at work with his flowery shirts. As a software developer the nature of the work was that if something went amiss at a client site during the warranty period, we had to send someone to look into the problem if it could not be resolved over the telephone. This was the pre-Internet days, there was no remote login capability to solve issues.

  Harry recounted that one client had an issue with a simulator component, but there was no one available with knowledge of that component, so Harry picked up the device manual, read it on the airplane on the way to the client, and fixed the problem at the client site. This was the culture of our group; we did whatever it took to solve the issue and keep the client happy.

Christmas Party

Below are some familiar faces from a Christmas dinner party I organized for the OSU team. This was at a downtown hotel and we brought our spouses along. I can't recall everyone's name who attended. The girl to the right in the last picture is Nadine (I don't remember her last name). She was, at one time, the only woman in our group.

CAE used to hold Christmas parties for their employees and spouses every year. When I started working there, very few of my peers attended the party. Mostly it was the more senior folks that attended. The first party I attended was a small gathering at the Royal St. Lawrence Yacht Club. Harry and our secretary were there but I didn't know anyone else there, certainly seemed to be mostly management folks. The food was great. It was a posh and very cozy place to celebrate.

As the years wore on, more and more people attended the party. The Yacht club was too small and expensive to accommodate a larger crowd, so parties were catered and held at the plant; not the same experience, but hats off to CAE for hosting Christmas parties for their employees. I'm not sure if this is still going on but a lot of companies no longer hold parties for their employees. Mostly team luncheons these days rather that corporate wide Christmas parties.

CAE as a Workplace

Overall I would recommend CAE as a great starting place for young engineers and computer scientists. I'm not sure if you still get to travel the world as in my pre-Internet days, but the work is always innovative and interesting. You also get to work alongside very qualified peers which you can learn so much from.

Note: these are my recollections from the time I worked at CAE. I've always wanted to describe them but never had the time. So, here many decades later, I'm pulling this from memory. There could be some inaccuracies and issues I've missed but for anyone who has worked there during the 1980s, these experiences will hopefully be familiar.

Compiled on 05-27-2024 23:58:12