Real-time Euclid: a language for reliable real-time systems
IEEE Transactions on Software Engineering - Special issue on reliability and safety in real-time process control
The Spring kernel: a new paradigm for real-time operating systems
ACM SIGOPS Operating Systems Review
Scheduling Periodic Jobs that Allow Imprecise Results
IEEE Transactions on Computers
Supporting real-time concurrency
Supporting real-time concurrency
The operational versus the conventional approach to software development
Communications of the ACM
Toward a discipline of real-time programming
Communications of the ACM
Responsive Computer Systems: Steps toward Fault-Tolerant Real-Time System
Responsive Computer Systems: Steps toward Fault-Tolerant Real-Time System
Foundations of Real-Time Computing: Scheduling and Resource Management
Foundations of Real-Time Computing: Scheduling and Resource Management
Foundations of Real-Time Computing: Formal Specifications and Methods
Foundations of Real-Time Computing: Formal Specifications and Methods
Hi-index | 0.00 |
In this paper we overview our work on Cleopatra, an object-oriented specification and programming language, and show how Cleopatra was instrumental in the design and testing of a sensory-motor robotics application using a generalization of Brooks' subsumption architecture. The specification of a real-time software control system is often the result of a process, whereby a conceptual control system is eshed out as a computer program. To be accurate, this process must abide by operational (e.g., timing or synchronization) constraints, which necessitate that knowledge about the available computation resources be utilized. Cleopatra is unique in that, unlike most traditional programming languages for non-real-time systems, it does not abstract away the details of the underlying machinery (e.g., hardware and operating system). By subjecting programmers to (at least some) limitations of the underlying machinery, the likelihood of timing failures is greatly reduced because programmers must write programs that are cognizant of these limitations. Unrealistic systems - possessing properties such as infinite capacities or perfect timing - cannot be specified. This preventative approach at the specification level is likely to spare a lot of time and energy in the development cycle - not to mention the elimination of potential hazards that would have gone unnoticed.