Transputer control of a flexible robot link

The applicability of transputers in control systems is investigated. This is done by implementing a controller for a flexible robot arm with one degree of freedom on a system consisting of an IBM-AT and four transputers. It is found that a control system with transputers offers a great improvement compared with conventional digital control systems. Transputers can solve the common problem in control practice, i.e. having very sophisticted controllers but not being able to implement them because they need too much computing time. However, transputers are not an optimal solution for more sophisticated control systems because of shortcomings in the scheduling mechanism

Safe and Verifiable Design of Concurrent Java Programs

The design of concurrent programs has a reputation for being difficult, and thus potentially dangerous in safetycritical real-time and embedded systems. The recent appearance of Java, whilst cleaning up many insecure aspects of OO programming endemic in C++, suffers from a deceptively simple threads model that is an insecure variant of ideas that are over 25 years old [1]. Consequently, we cannot directly exploit a range of new CASE tools -- based upon modern developments in parallel computing theory -- that can verify and check the design of concurrent systems for a variety of dangers\ud such as deadlock and livelock that otherwise plague us during testing and maintenance and, more seriously, cause catastrophic failure in service. \ud Our approach uses recently developed Java class\ud libraries based on Hoare's Communicating Sequential Processes (CSP); the use of CSP greatly simplifies the design of concurrent systems and, in many cases, a parallel approach often significantly simplifies systems originally approached sequentially. New CSP CASE tools permit designs to be verified against formal specifications\ud and checked for deadlock and livelock. Below we introduce CSP and its implementation in Java and develop a small concurrent application. The formal CSP description of the application is provided, as well as that of an equivalent sequential version. FDR is used to verify the correctness of both implementations, their\ud equivalence, and their freedom from deadlock and livelock

CSP design model and tool support

The CSP paradigm is known as a powerful concept for designing and analysing the architectural and behavioural parts of concurrent software. Although the theory of CSP is useful for mathematicians, the programming language occam has been derived from CSP that is useful for any engineering practice. Nowadays, the concept of occam/CSP can be used for almost every object-oriented programming language. This paper describes a tree-based description model and prototype tool that elevates the use of occam/CSP concepts at the design level and performs code generation to Java, C, C++, and machine-readable CSP for the level of implementation. The tree-based description model can be used to browse through the generated source code. The tool is a kind of browser that is able to assist modern workbenches (like Borland Builder, Microsoft Visual C++ and 20-SIM) with coding concurrency. The tool will guide the user through the design trajectory using support messages and several semantic and syntax rule checks. The machine-readable CSP can be read by FDR, enabling more advanced analysis on the design. Early experiments with the prototype tool show that the browser concept, combined with the tree-based description model, enables a user-friendly way to create a design using the CSP concepts and benefits. The design tool is available from our URL, http://www.rt.el.utwente.nl/javapp

Automatic generation of scheduling and communication code in real-time parallel programs

Inter-process communication and scheduling are notorious problem areas in the design of real-time systems. Using CASE tools, the system design phase will in general result in a system description in the form of parallel processes. Manual allocation of these processes to processors may result in error prone and/or slow communication code. Scheduling of the processes, necessary to meet timing constraints, is also a tedious task that takes many iterations. The described design tools result in code that is comparable in quality and performance with expert manual realization. Many network layers have been implemented to relieve the user from the low-level programming of communication software. However, the increase in user-friendliness is usually paid with performance degradation. The proposed approach combines user-friendliness with high performance by generating communication software that is tailor-made for the application. A similar approach is followed with the scheduling software. Schedulers in the form of a built-in a kernel are available all the time and cause overhead all the time. The proposed preprocessor tool generates scheduling software after analyzing the timing requirements of the particular application. This results in simple code for simple timing requirements and more complicated code for complex timing requirements. The tools have been implemented in Occam for use on a transputer. However, the results are valid for any distributed memory machine

Implementation of KRoC on analog devices' "SHARC" DSP

This paper summarises the experiences gained at the Control Laboratory of the University of Twente in porting the Kent Retargetable occam Compiler -KroC -to the Analog Devices' ADSP21060 SHARC Digital Signal Processor. The choice of porting the KRoC to the DSP processor was in our view both a challenge and an absolute necessity because DSP processors are an important ingredient in modern day control systems. Currently, our implementation contains the most important occam primitives such as channel communication, PAR, ALT, and most of the integer arithmatic. Furthermore, a basic kernel was realised, providing channel-communication based scheduling only. This porting process, using quite straight-forward modifications of the SPARC KRoC-translator, was done within six weeks. A representative benchmark was constructed, showing that the 33Mhz SHARC-KRoC implementation is 40% faster than the the 25Mhz T800 using the INMOS D7205 Toolset

CSP for Java: Multithreading for all

Many internet, real-time and embedded applications are most naturally designed using concurrency. Unfortunately, the design of concurrent (multithreaded) programs has the reputation of being extremely difficult and dangerous, due to the possibility of deadlock, livelock, race hazards, or starvation - phenomena not encountered in single-threaded programs. Lea [1] emphasizes concern for the apparent difficulty: "Liveness considerations in concurrent software development introduce context dependencies that can make the construction of reusable components harder than in strictly sequential settings." Two approaches he suggests for design sound tedious and perhaps risky: "Top-down (safety first): Initially design methods and classes assuming full synchronization (when applicable), and then remove unnecessary synchronization as needed to obtain liveness and efficiency...Bottom up (liveness first): Initially design methods and classes without concern for synchronization policies, then add them via composites, subclassing, and related layering techniques..." Both suggest lengthy sessions of patching and testing until the application appears to work as desired. Even those intimately connected with Java seem reluctant to employ more than a single thread. The Swing documentation states "If you can get away with it, avoid using threads. Threads can be difficult to use, and they make programs harder to debug. In general, they just aren\'t necessary for strictly GUI work, such as updating component properties" [2]. Oaks and Wong [3], also associated with Sun, are more positive, but note that "Deadlock between threads competing for the same set of locks is the hardest problem to solve in any threaded program. It\'s a hard enough problem, in fact, that we will not solve it or even attempt to solve it." Later they state "Nonetheless, a close examination of the source code is the only option presently available to determine if deadlock is a possibility..." and add that no tools exist for detecting deadlock in Java programs. We feel, however, based on fifteen years of experience, that concurrent approaches are the best way to design most programs. Done properly (e.g., using CSP [4]) this results in better understanding of the problem and the solution, and leads to much cleaner implementations. A tremendous amount of work has been done on and with CSP in recent years, and the present state of the language and the tools offers the Java programmer excellent facilities for the design and analysis of multithreaded programs. Furthermore, Java designs based on CSP class libraries can now be verified against formal specifications and checked for deadlock and livelock with CASE tools - prior to implementation. We present the CSP model (processes, channels, events, networks) and its binding into (100% Pure) Java through the CSP class libraries developed at Kent [5] and Twente [6]. We describe some of the tools associated with CSP (e.g., FDR [7]) and demonstrate, in several practical applications, their use for checking specifications and proving the absence of deadlock. We emphasize that CSP concepts are easy to understand and apply and that the engineering benefits they confer on system design and implementation are significant for both real-time and non-real-time multithreaded systems