Click on this image to see a full screen shot.
Because of my success working with the IBM team, I was selected to lead the technical team performing due diligence investigation of some intellectual property Avaya wanted to purchase from a company, iSpheres, that had declared bankruptcy. The software was an application the performs Complex Event Processing.
I was very impressed with the quality of the software I inspected. The iSpheres team had done a good job of documenting the code and had a very good build and automated test setup. The product's key feature is a very efficient event engine and a language, Event Processing Language (EPL), used to configure the system to build applications based on Event Driven Architecture (EDA) principles. Based in part on my recommendation, Avaya purchased the software. I was made the development leader for the team in charge of Avaya-tizing and productizing the software, which was re-branded as the Avaya Event Processor.
In planning sessions with my new manager (who was the former Vice President of Engineering at iSpheres), we decided that an agile development process would be a good fit for our project. I boned up on Scrum and became the project's scrum master. We have had great success using this process and I am really sold on the benefits of agile development.
One of the more interesting applications we built using the product was an RSS keyword notifier. We created an "Input Adapter" that monitored a set of RSS streams. Users could register keywords of interest from a web interface, along with other criteria, such as the number of times the keyword would need to be detected in a given amount of time to generate an alert and how often a keyword could generate an alert. The keyword search and constraints were implemented in EPL. When the keyword is found in an RSS article and the other criteria is met, the system sends an alert to the user via the Avaya Communications Process Manager. This notification can be in the form of a call, SMS message, or e-mail. See below for an example of an e-mail notification. Note that the notification includes a link to the original article, simplifying user follow up. We trialed this application with a customer in the entertainment media industry and received compliments on the product.
Click on this image to see a full screen shot.
Click on this image to see a full screen shot.
In what amounts to yet another milestone in my career, I changed gears and moved into "pure" software development. As part of the Application Enabled Services group, I helped develop a Java-based middleware application that integrated telephony with the web. The product, Meeting Exchange Groupware Edition for Sametime, integrates Avaya conferencing services with the IBM Sametime web meeting application, allowing tight integration between web and telephony conferences.
I had decided it was time for a new challenge and so when the opportunity presented itself to work on a java project, I jumped on it. A lot of great things occurred because of this move. First, I learned a new language that I really enjoyed developing in. Second, I was exposed to how powerful agile development can be. And third, I got to work with a great team of developers and test engineers (our test team was in Dublin, Ireland). We used a design based on the command pattern to ensure a clean separation between the IBM threads and ours, which send commands to our conferencing bridge. To do this, we used Doug Lea's concurrency library. I was impressed with how easy multi-threaded programming is with this library. I am stoked that it was included in Java 5 (changed a little, but the important stuff is there).
While I was not the most experienced Java developer on the team, I was able to contribute from the get-go, providing input on the API between the IBM product and ours. I also became the principle liaison between the IBM technical team and ours. In the midst of all of this, I actually became extremely proficient at Java development as well.
Variations on a theme, the above products are VoIP telephony gateways. These products allow customers to interoperate between VoIP and traditional telephony systems. VoIP, or Voice over IP, allows calls to be placed using a data network as the transport infrastructure (this network could be a local intranet, a private dedicated network, or the Internet). But much of the world still doesn't have access to VoIP. To bridge the gap, a gateway is used to intelligently route calls over the correct medium, be it the network, an analog or digital line, or an ISDN trunk, typically via POTS (plain old telephone system). Each of the above product is similar in nature, but sized for a different number of users. Internally, VxWorks was used as the real-time operating system for these products. The code was a mix of C and C++. My principle contributions to these products were in two areas, performance and ISDN signaling.
As part of the gateway performance team, I redesigned an existing resource scheduler that was taking too many CPU cycles to complete. The original code was written in C. My implementation used C++ and improved the performance of the scheduler by 10%, which reduced CPU usage by 2%. In another incident, utilizing my knowledge of C++, I suggested a change in how exception declarations should be coded that resulted in an improvement of 40% in call processing times. This improvement ended up being the difference that allowed us to meet our call processing requirement.
My other area of responsibility was in support of ISDN signaling. ISDN signaling uses a protocol called LAPD, which I became intimately familiar with. I ported a legacy LAPD module from another PBX product into the gateways. During the port, which was written in C, I designed and implemented a LAPD protocol sniffer that allowed the gateway to capture all LAPD packets sent and received. Using this tool, I was able to remotely diagnose a setup in France in which the ISDN network was incorrectly wired. My counterpart in France was extremely grateful and passed on thanks from the customer as well. He remarked that in previous products, an external network analyzer and at least a couple of extra days would have been required to find the problem. This was a "Good Day"TM.
Towards the end of my stint with Converged systems, I designed a next generation ISDN Layer 2 (LAPD/Q.921) architecture for use in the gateway product line. The design used a C++-based object-oriented state machine framework. This architecture was adopted after I left the group and developed by the gateway team. I was complimented by the team on how well I had documented the architecture and how easy it was to pick up where I had left off.
The product that started it all, this was the first product I worked on as JEKLsoft. A manager from a previous job contacted me, asking if I knew someone who could take on a small contract job designing software for a new pressure sensor his company was developing. I was intrigued and decided to take on the job.
I wrote the firmware for the Display Controller Module of this instrument. This firmware controls the LCD display, push buttons, RS-232C control port, remote command and control, and communication between the two pressure sensors. The other cool feature I implemented was a leak detection mode for the device. In this mode, the device monitored the change in pressure and drove a speaker in the device. This mode allows the end-user to move a portable wand around a pressure vessel looking for leaks without having to monitor the display.
The processor used was a PIC 17C256 and the code was written in C. Since I had been working on fairly high-level software for quite a while, it was fun "getting back to my roots" and doing some bit-banging. The marketing requirements for the product specified a high level of functionality while the engineering requirements specified that the code be easily maintained. Midway through the project, we discovered that program memory would be very tight. I really had to tighten up the design, squeezing every program word I could out of the code. The customer was extremely happy with the end product, both in terms of functionality and maintainability.
The 2400 was the next-generation compounder at Baxa. The device supported up to 24 ingredients and supported "micro" ingredients, which are ingredients in which less the 5 ml are required (the 2400 could pump as little as 2 ml). Previous compounder products required a separate computer to operate them. In the 2400, we included an embedded PC and touch screen, so the unit worked stand-alone.
Much of the software was reused from a previous compounder (EM 600) project. If I hadn't already been sold on object-oriented design, this project would have sealed the deal. As it was, I was able to convince many others of the paradigm's power. Two days after receiving working hardware and the drivers for the EM 2400 hardware, we were able to control the new unit with the existing software. We received a standing ovation from the sales force after the demonstration. That really felt good!
I started working on this product as an employee of Baxa. After I left Baxa, I was asked to return as a consultant. Baxa was JEKLsoft's second customer.
Compounders are medical devices used to prepare IV admixtures for patient use. At Baxa, the compounders were typically used for the creation of nutritional IVs, which include a combination of amino acids (proteins), dextrose (carbohydrates), lipids (fats), and trace minerals (potassium, calcium, etc.). The 600 supported up to six bulk ingredients. The software interface allowed a pharmaceutical technician to input a specific prescription and then request that the compounder prepare the IV. The software first checked for certain safety parameters and then designed a sequencing algorithm that ensured a safe mixture. An example of this is that calcium and potassium solutions could not be pumped in close proximity to each other (failure to ensure this could cause dangerous crystals to form in the mixture). As the ingredients were pumped, the software monitored the weight of the pumped compounds to ensure that the mixture was accurate.
When I first started with Baxa, I revamped a DOS-based BASIC program designed to control this compounder. After completing that project, I got to design and build the next generation version of the product from the ground up. Using Borland Delphi, the product was developed to run under any 32-bit version of the Microsoft Windows operating system. I knew the EM2400 was in the pipeline and so I chose an object-oriented design that would maximize reuse in the new compounder. The design allowed different pump drivers to be installed in the back-end and different GUI's to be installed in the front-end. The other 75% of the software, including sequencing algorithms, adjust algorithms, database storage, and utility modules, remained the same.
Click the image above to view a small slideshow.
My work on the VX4101 and Vx4101A represented my first lead design role. I was given free reign with regard to the software architecture. Even though the system was embedded, I decided to use C++ and OOP on the product. This was my first foray into object-oriented design. I encapsulated the concept of an "instrument" into a base class and then inherited from this base class for each instrument on the card. It worked very well and made adding new instruments into the architecture very straight-forward. I received a "Software Achievement Award" from Tektronix for this architecture.
The VXIbus, which is an extension of the VMEbus, was designed with card-modular instruments in mind. The idea was that instead of requiring an entire 19" rack mount box for a single instrument, a box would hold up to 13 instruments each of which would reside on a single "card" that could be plugged into the box. We took the next step with the MultiPaq and put multiple instruments on a single card. The VX4101, centered on an MC68330 CPU running VxWorks, contained a 5.5 digit DMM, 250 MHz Universal Counter/Timer, and SurePath switching control in a single slot VXIbus module. The VX4101A added 8 DAC channels, 32 Digital I/O channels, and 8 relay drivers to the VX4101.
Unfortunately, Tektronix decided to exit the VXIbus market. These products were removed from sale in early 2001. I was really bummed because this was a great product.
Click the images above to view larger versions.
The VMEbus, circa 1986-1989, was a 40 MHz, 32-bit data bus standard. My first job out of college was building data collection and processing systems for Lockheed Missiles and Space (now Lockheed-Martin) based on VMEbus products. Most of the details regarding what I did at Lockheed can't be discussed, but I can provide some general descriptions.
The systems we built were based on Motorola 68K processors. All of our code was written in 68K assembly language using a custom real-time operating system written by my good friend and mentor, Jay Weyermann. It was designed with extreme efficiency in mind and while it met that goal handily, it was still remarkably easy to use. In the system above, data was collected using a custom digitizer and was fed to a bank of algorithm processors for manipulation. We used GPIB and DR11W interfaces to control the surround equipment. One of my first assignments was to rewrite the Motorola CPU ROM monitor so that it used our ethernet interface rather than the onboard serial port as the principal I/O mechanism. The protocol was based on DECnet and allowed for telnet-like remote debugging of the code. I also worked on a local keyboard and printer interface.
Another system I helped design and build (which I don't have pictures of), contained two 68K CPU boards, 32 MB of VMEbus RAM, four Mercury array processor boards, a custom 80 MB high-speed RAM array, a dual channel 80MB/s 10-bit digitizer, and an optical storage sub-system. The whole thing was controlled using an even more powerful assembly-language based, real-time operating system, BlackBird, also designed by Jay. If these numbers don't sound extremely exiting, remember that this was in 1988!