This post is part of the SATF work.

This is a good time to review Microsoft Robotics Developer Studio architecture, since all the following will use the terms and notions of that system. Quite naturally, it strongly influenced simulation testing framework algorithms design and data structures. MRDS is a .NET-based framework which consists of three main components: DSS, CCR and simulation engine, plus tooling.

CCR stands for Concurrency and Coordination Runtime. As the MRDS documentation reads “The CCR addresses the need to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. It enables the user to design applications so that the software modules or components can be loosely coupled…” Essentially, it is an implementation level library providing the modern paradigm of dealing with asynchrony and concurrency. The CCR’s messaging primitive is called a port, basically, a FIFO queue responsible for relaying of a particular message type. A number of ports could be combined into a port set, a way of bundling the messages together, amounting to some kind of program interface. Coordination of the incoming messages is the responsibility of arbiters, ranging from triggering on individual messages on individual ports (Receive), to triggering on any message on a port set (Choice), to triggering only on all messages on a port set (Join) etc. The CCR dispatcher manages and load balances scheduled handlers. CRR determines the implementation aspect of the testing framework and influences the design of the system least of all.

DSS, meaning Decentralized Software Services, provides a runtime environment, development infrastructure and a service-oriented software model that is supposed to cater for scalable, robust and loosely coupled applications. A service is a program unit within MRDS framework: every MRDS program, including all the infrastructural services and even simulation engine itself, is a service (although the simulation engine is a bit more equal than others). Each service has a contract – its external program interface. It consists of a unique name, a service state declaration and a set of operations with REST-like semantics (like Get, Update, Delete etc.). Complex systems consist of several interacting services, whose composition and interdependencies (called partnerships) are stated in manifest files. The DSS runtime hosting environment handles launching of such files as well as all the other tasks related to the service lifetime control and management. DSS also provides a lot of other powerful capabilities like built-in support for service state persistence, service contract inheritance and an event notification mechanism.

The last component is a simulation engine. It consists of the physics and graphics simulators, the latter of which could be turned off at request. A unit of simulation, called entity, could participate in both types of simulation. Entities participating in physics simulation might be controlled via applied forces, set velocities or other means. And, of course, simulation engine provides access to the physical state of all simulated objects. Special entity services interacting with simulator expose simulation entities to the service level allowing external services to control them. They abstract the simulator from the rest of the program, so that the real devices could be substituted for the simulator entities later on. The simulation engine, being a service itself, can also persist its state, which could be considered as a snapshot of the simulated physical environment. Also the simulator provides a peculiar capability of freezing time flow.

At the moment of choice, MRDS seemed to be a quite potent and perspective product. It had a functional physics simulator, modern concurrency paradigm and comprehensive infrastructure and tooling. But the most appealing MRDS property was the freedom to write programs in the C# language, enjoying all the advantages of a modern object-oriented language with enterprise level environment and community. As a matter of fact, MRDS as a product did not disappoint me, Microsoft as a product owner did when it stopped its support and development.