Das kleine Ingenieurbüro
... mit der großen Bandbreite
Details about completed projects
Summary of Development activities and customer projects 1979 - 2001
1979-1986 Technical University (RWTH) Aachen
First contact with microprocessors. Development of a first Eurocard-sized Z80 System. This system runs a simple monitor (ZappleMon) program and gets extended by Editor/Assembler. After writing a suitable BIOS CP/M 2.2 runs on the system.
1980-1984 Employment at Institute for Regulation Technology (IRT)
First contact to real-time-excutives
A project in the IRT makes use of the IRMX-85 realtime executive from Intel. The reverse engineering shows tht it is written almost completely in PL/M. Due to the limited compiler technology at that time this results in a large memory footprint and rather slow operation. I decide to rewrite the kernel in assembler, cutting its memory requirements from 8kBytes to less than 2 kBytes with a twofold increase in speed. Later versions of this kernel replace the mailbox-oriented intertask communication paradigm of the IRMX85 by non-counting semaphores for flexibility: critical regions can be locked by semaphores, thus allowing easy implementation of complex application-specific communication structures. Interrupt-routines, unable to dynamically allocate messages can trigger task level processing simply by setting semaphores their task level counterparts are waiting at.
HAL1 - multiphase transient recorder
For the institute of pharmacology of the university of Cologne a multiphase transient recoder is developed and built, sampling the high-speed depolarization phase of an intracellular myocard action potential at 100k samples/second (ksps) and the following repolarization at 10 ksps. A second channel samples the physical force exerted by the test tissue at 4 ksps to make all data from one contraction fit into less than 32k of memory.
HAL2 - Averaging data recorder with sample vector processing unit
EEG potentials often consist of a small signal correlated with a stimulus hidden in a larger uncorrelated signal. In order to extract the correlated portion a typical method is to take sample sets synchronous to the stimulus signal and add the sets. In this way the random uncorrelated signal diminuishes against the correlated part. HAL2, again based on a Z80 is able to do this correlation in hardware: The sample memory subsystem consists of 16bit-wide memory, a sample counter, bit-slice-ALU and logic. For each 8-bit sample the contents of the associated memory location is fed into one input of the ALU, the sample is sign-extended ad fed into the second input of the ALU. The result is then stored back into the memory and the sample counter is incremented. After each sample set the memory is read out and its contents displayed on an oscilloscope-like display for on-line recording quality control.
After correlating a predetermined number of samples the result can be stored for postprocessing.
1986 - M.S. Degree from RWTH Aachen, Germany
Master's thesis project is development of a pulsed current power source for electroerosion milling. At this time use of power mosfets for switched mode power supplies is rather new. The power supplies employ digital regulation and isolated driver stages. The units are designed as switchmode constant-current sources, providing up to 10 Amps at 300 Volts open-circuit output with on/off switching times below 100 ns.
STATE A language for description of finite automata
In the early 80's PALs (Programable Array Logic) get accessible for students and offer interesting possibilities to implementing finite automata in single chips. However one drawback is the lack of a standard alphanumeric description method for automata : Karnaugh diagrams and State-Transition diagrams are the methods of choice, both requiring graphics processing capabilities. The design of the STATE-Language addresses this issue: States are numbered, Input bits are named and both conditional and unconditional state transitions can be defined. (See here for details)
The language, being basically designed only for documentation purposes, allows an interesting processing step: The automaton defined in STATE can be compiled into logical equations which subsequently can be fed to the PALASM program and programmed into PALs (theory)
One of the first applications for the state-compiler is the implementation of a set of control PALs which provide the arbitration of a shared memory segment between a Z80-Processor and a 6845 raster scan controller in the ELSA product "TIPS50", a single board terminal.
FORTH
General interest in high-level-languages leads to FORTH, a high level language interpiler with a very small memory footprint. For another ELSA product, the "TIPS100", a combined alphanumerical (25x80) and APA-graphical terminal I develop a small FORTH interpiler to allow effective macroprocessing in the graphical environment: All graphics operations (draw line, ellipsis, arc, flood fill ..) are implemented as forth primitives which may be used in subroutines. This method takes very much load off the 19200 bps serial connection to the host.
APOBOX
Again for ELSA, in the early days of modem communication in Germany, in cooperation with a software company "APOLLO" we design and implement the APOBOX. This unit, running on our Z80-Real-Time-Executive is used as a connecting link between an IBM mainframe and the public telephone network. Some events in the mainframe get communicated to the AOBOX which then alerts operators by calling them on the phone. This unit is used in the advent of operatorless IT operations. Later the modem, used only as a dialing unit, gets replaced by a speech-output and- DTMF-input unit provided by SpeechDesign. A still later version addressed problems in home-banking industry included monitoring of the accessability and presence of BTX-pages for a german bank. When the BTX pages got unavailable the APOBOX informed the operator, who then could locate and fix the
HAL3 (1986)
Dr. Dhein, pharmacologist at the University of Cologne needs a data recorder capable of recording the surface potential distribution on isolated hearts, mV-signals at kHz recording rates, many channels being sampled simultaneously. We decide for a multiplexed 256 channel front end again based on a z80, equipped with high-impedance CMOS input amplifiers and delivering its data to a standard PC. After several hops of its owner up the academic ladder with the associated moves the system is still in operation, now at the Heart Center Leipzig.
1986-1988 Employee at Intercope, Hamburg.
Development of the Intercope TelexBox
The TelexBox is a autonomous multichannel telex transceiver. It connects with up to 4 lines to the public telex network, a host system is attached by a serial asynchronous connection. It stores documents in up to 4 megabytes of battery-backed memory and schedules transmissions and retries autonomously. Based on a Z80 running the author's real-time executive everything except for some C-library functions is has been written by the author.
The TelexBox is marketed in many countries, various country-specific adaptations exist. PTT Approvals exist for virtually all countries operating a telex network. The system is still being produced, telex is still an interesting niche market.
Development of a distributed process monitoring system for Berlin Water Supply
NTO (network-Transport-Optimizer) is a distributed process-data-acquisition, -transport, -derivation and -display system. Process data from wastewater pumping stations is acquired by measuring frontends located in the pumping stations. This data is scaled, derivative values (i.e. pump efficiency derived from electrical current consumption, water flow and backpressure) are calculated. The results are displayed on DOS-PC-based graphics workstations located all over Berlin. Data transport is provided through a private low bandwitch TCP/IP-Network. Efficient usage of the network bandwith is essential, so a on-demand acquisition and transport protocol, called NTO, was developed.
The system is based on the concept of process variables and nodes. A process variable is a data entity which is continuously being updated by a process on a source node. A node is a computer running the nto software, being embedded in a network of neighbor nodes and possibly running one or more data source processes (which update process variables). Each node also runs a communications server process where neighboring nodes and local workstations may log in to gain access.
When a user intends to display a process image containing some process variables on his local workstation the workstation logs onto its local node and requests delivery of the variables. Variables which are presently available are delivered immediately. Arriving updates to a variable are forwarded to the connected consumers. If a variable is presently unsupported by the node (no local consumer currently requires the value), the node looks up which other node provides the variable in question and requests delivery of the variable from either directly the node running the source process for the variable or the next node sitting on the way to the data producing node.
Assuming that the network topology is modeled exactly like the physical network (the logical links being in the same places where the physical network wires are) this method guarantees that every datum is at most transmitted once over any network link.
The complete system, including the graphics display software on the PCs, is developed by me and my team members.
Automation of batch polymerization plant, CHZ Sokolov (Czechoslovakia)
A complete 5 lanes wide plant for overlapping batch production of acrylic copolymeres is automated. Store management and materials allocation runs on a UNIX S5V4 Host, each lane runs on a 68040-based PDOS Host
The system implements an early object-oriented approach: Manager processes host Objects (Scales, Valves, Mixers, Thermoregulators ...) of varying complexity. All objects communicate through a intranode message network. Complex objects usually employ simple objects. Remote objects implemented on other hosts are represented by network agents on each node, forwarding requests and replies over an ethernet.
The top level objects are usually batch managers, accompanying a production batch through raw materials allocation, monomere mixing according to recipe, polymerisation, cooling and filtering, storage into product holding tank to materials and product billing.
Human interaction is by virtual alphanumerical terminals kept in memory, each with a single input line and a square output section. A terminal manager process allows overlapping display of a multitude of those terminals simultaneously on a serial terminal.
PDOS, being weak in interprocess communication, gets extended by a loadable process intercommunication subsystem developed by the author.
The commercially available TCP/IP-Implementation for PDOS is unuseable, partly due to its enormous memory consumption, partly for enormous bugs. The answer is a small, self-developed UDP-like Network messaging system which interfaces to the messaging part of the interprocess communication module. Everything including the driver of the AMD LANCE network chip is implemented in just 16k of memory.
Development of Ethernet sniffer for PCs
Reverse engineering of the protocol used by Siemens to interconnect their Simatic control processors requires knowledge about the frame contents. Project budget limitations made it impossible to either acquire support from SIEMENS or to buy an ethernet protocol analyzer which were still very expensive at that time (1990). The network sniffer was written in C and ran on a PC with a Novell NE1000 card which was an exact copy of National's reference design for the DP8390 ethernet chip.
Attachment of PDOS to SiMatic5
This project implemented the SiMatic5 network protocol on a PDOS-based realtime system. Reverse engineering of the protocol between two Simatic nodes identified the protocol as a derivative of the standard ITU Transport layer.1991-now : Independent Engineering Bureau in Hamburg}
AIX-based Telex System
Intercope of Hamburg implemented the telex backup portion of the interbank messaging system from SWIFT (Society for worldwide interbank financial transactions), Brussels. A flexible interface for various country-specific telex frontends was required. The author developed a Message-to-Line interface based on FORTH as a scripting language. Country-specific adaptation is done by loading the appropriate script.
Software for Hyperstone RISC-Processor
The hyperstone processor, a 32-bit RISC processor from a german company, hyperstone in Konstanz, was chosen as technology base for a range of products at hypercope, (former intercope electronics), a spinoff from ELSA and Intercope developing products for the emerging ISDN market in 1991
The first hypercope product was a ISA-bus based active ISDN coprocessor with no rom. Bootcode was written into a portion of the dual-ported RAM and then the hyperstone was started to load the operating system into its memory. Every piece of the boot code, both on host and hyperstone, was written by the author.
Hyperstone distributed their realtime kernel as closed source first. This binary kernel failed to run on other hardware than the hyperstone reference design board. Hypercope, being in the urgent need of an executive for their platform, decided to go with the author's recommendation to write it's own real-time executive. Due to the excellent design of the hyperstone timer unit this OS was the first to provide microsecond timing resolution without the overhead of recurring timer interrupts.
Development of dynamic communication-protocol-stack framework for Hypercope
In order to make efficient use of the multi-media ISDN network the author developed a complete framework to establish arbitrary communication protocol stacks. \nbsp;Click here for more details
Technology transfer between German customers and Indian software company
In 1993 one of our customers outsorced a software evelopment project to an Indian, Bangalore-based software company. We managed the technology transfer process, mediating between the cultural differences and respective expectations.
Experience showed that in order to succeed in such outsourcing attempts both sides must be continuously monitored and led. Requirements, design specifications and clarifications have to be passed to the work force while results and, requests for specification refinement and questions flow back to the principal. The mediator must have in-depth knowledge of the project subject and must be capable of communicating with both sides, technically and socially. Typically the best software specalists found are quite incommunicative.
Missing
Expansion of NTO (Berlin) to UDP Transport and Interface to Siemens
The management of the Berlin Water Supplies decided to buy automatization software from SIEMENS to remote-control their waste-water pumping stations. This SIEMENS system is unable to provide process data of the controlled station outside of the remote control itself. In order to conserve the availability of process data (pumping speed, pressure, wastewater destination ...) of the whole system SIEMENS had to extend their software by an interface to the existing NTO (see above). The new interface between SIEMENS and NTO was decided to employ UDP to allow graceful service degradation in the case of traffic congestion. After participating in the definition of the interface the author wrote the NTO-side interface process.
C-Implementation of communication protocol modules
As of 1995 all ELSA ISDN-products were Intel-80186-based, coded in assembler. In order to gain portability all protocol modules had to be rewritten in C. First candidates were X.75, V120 (Data Link Layer), T70 (Network Layer), and the physical layers doing HDLC and bittransparent traffic with the SIEMENS range of BRI ISDN interface chips. Later a V.110 module followed to allow communication between ELSAs ISDN devices and GSM-attached stations in order to enable dialup of company networks from cellular phones.
Development of realtime executive for Hitachi SH3, ARM7
ELSA decided to implement new ISDN and modem communication devices on non-intel platforms. This creates the necessity of a portable framework to port their existing comunication software to. To remain free in the choice of the implementation platform for the GNU C-Compiler/Assembler/Linker suite was employed as development tool suite. A new portable realtime executive was tailored to both fit the API of the modules ported from the older ix86 environment and provide optimum performance for the class of devices planned.
A comparison result from the development of the first new LanCom product : A floodping of 4000 ping frames in very quick succession was sent to an old (x86-based) LanCom, a competitors product and the new, SH3-based Lancom with the new executive. The old LanCom replied to 25 frames, the competitive product returned 65, the SH3 LanCom replied to all 4000 frames!
The source tree based on those efforts has since become the technological base of many communication products from ELSA.
Design and Implementation of early-AFDX Ethernet-switch as a linux-kernel-module for AIRBUS
In the advent of the development of the A380 airplane AIRBUS searched for possible replacements of the legacy communication buses and -protocols employed in airplanes. Full-duplex-ethernet turned out to be one possible candidate. We participated in the early discussions about the feasability of Ethernet-based secure airborne communication. In the process we developed a software-driven packet switch with 8 ports implemented as a kernel module on a PC running Linux. The switch stalled at feeding through approx. 50.000 frames/second on a 166 MHz Pentium-MMX system. A set of PC running this software implementation of an early AFDX switch was built and delivered to AIRBUS Together with some quickly written demonstration tools like a joystick to AFDX-protocol program and an AFDX-to-crosshair display a small aeronautics-related demo was set up, showing the insensibility of the system of failure of a single link in a redundant set-up.
Implementation of V.23 and DTMF modulation for 8kHz PCM systems
In order to implement CLIP (Calling Line Identification Procedure) on the small PBX products of ELSA an effective DDS (direct digital synthesis)-based modulation algorithm for both V.23 (1200 Baud FSK) and DTMF was developed by the author. Part of the code will be used in the Linux Soundcard Dialer Gadget.
Design and implementation of a universal firmware-loader framework
Growing firmware sizes for complex datacom products together with a widening gap in memory prices between classic, random-access eeprom/flash memory on one and sequential/nand-flash memories on the other hand led to the decision to design a bootloader able to boot from serial memories. The underlying idea is to conceive any boot data, independent of it's transport channel, as a data stream in opposite to a memory image. The result of this project was a highly portable and flexible boot architecture, which in conjunction with a controller with small on-chip rom (i.e. Hitachi SH-1) allows assembly of products with completely unprogrammed flash roms. The products can then be initialized and personalized during manufacturing end-test. No test software ever needs any rom space, thus reducing rom memory requirements.
Development of NAS System
During the boom phase of the new economy a joint venture between a german and an american company was formed with the mission to complete the development of a "serverless file server" system, today known as NAS = "Network Attached Storage". From the american partner this project inherited two proprietary hardware platforms for the project and a set of leads to possibly usable software subsystems. Although primarily looking good this heritage bore a lot of problems : The nonstandard hardware platform lacked support from the OS vendor, the third-party file system modules licensed lacked the promised portability, crashing endlessly on a non-Intel-X86 machine, the american partner got bought out of the market, leaving the startup without any useable marketing... Finally the product was finished, still on this proprietary hardware platform but now on a self-ported Linux using open source software, only to wait for marketing never to be undertaken.
Set-up and administration of Linux-based network including fileserver, webserver, printserver, CVS, VPN, NAT andFirewall
Leading the software portion of the above mentionend NAS project the need for IT infrastructure was satisfied by setting up a couple of linux boxes providing all the required services. The author used this experience to deepen his knowledge of current network protocols.
Representation on COMDEX in USA
Implementation of realtime executive on ppc603 and i960
In the NAS-project we decided after a while to abandon usage of the formerly employed real-time-executive due to virtually non-existent support by the vendor. This kind of RTX seems to be only useable if either you use ready-made hardware with a board-support-package readily available or are a player with enough size and power on the market to really be able to threaten the software vendor. None of both options applied to us - a small company developing a product on their own hardware platform.
This need for a realtime executive was satisfied by just another kernel written by the author, this time for the intel960 and the ppc603 processor.
Device-drivers for ARINC429 interface cards under rtlinux
For a proof-of-feasibility demonstration of a cabin pressure regulator a working group within AIRBUS planned to use their ADS3000 simulator system. This system was set up to simulate the sensor inputs for a preprogrammed flight profile and to log values like cabin pressure, pressure changing speed and control valve positions. Communication to the ADX3000 was limited to ARINC 429-compliant modules from Tech S.A.T GmbH which had to run under rtlinuxThe author wrote the missing portion between the shared-memory interface of the A429-IP-module and some realtime fifos conveying simulated sensor data into and log data out of the regulator algorithm.