Orchestration

= Orchestration =

The orchestration layer spans the concert and is responsible for gathering and engaging the necessary components required to facilitate a solution and both the formulation and execution of services provided by that solution. This is a non-trivial exercise as there is no standard one-fix for all possible problems.

Background

 * Classifying Orchestration - a quick overview introducing several possible approaches to handling orchestration.

Objectives
We are seeking to enable service robotics - this immediately motivates a few objectives that are different to standard development for digital environments. Primarily we need to cater for the problems in environment, composition of resources and dynamism with a focus on services while at the same time (and this could be argued as the higher priority) we strive for eliminating complexity, enabling autonomy and robustness. The goal is for an easily configurable and reproducable environment, not a one-shot lab demonstration that can sacrifice these things in favour of other priorities.

Goals
Dynamism

Without committing totally to the complexity of a multi-agent paradigm, we'd like to introduce features that add dynamism above and beyond the usual notion of 'orchestration'. Robots and devices (concert clients) should be provided on demand, retasked when needed and to a minimal level, be able to make some decisions on their own (such as requesting for computational resources to execute software on the concert network).

Service Oriented Orchestration

We're doing service robotics! We would like a single solution to be able to offer multiple services in parallel (just as a pc server usually has multiple offerings such as web serving, file serving, ...). These services will probably be standalone and disconnected to keep the higher level system simple, yet practical. They should also be fluid. Rather than binding resources and workers to themselves, they should dynamically share the distributed set of resources working for the solution, capturing them when necessary and releasing them upon completion of the service.

Service/Solution Development Tools

In past experiences, we've found that managing diverse human teams (the customer, designers, system modellers, android/software/robot devs) is a very important part of the solution/service developer's role. This person was responsible for the big picture. In detail, this involved programming a small part of the glue and manually interacting with each separate group involved in the project. This is a very manual, tedious and error-prone process. From a practical sense, this problem is as important if not more than the technical solution. We plan to develop tools that can assist in automating and validating some of these processes, especially remote groups (think Social-Service Development Environment). Another aspect of this person's job is to test and confirm the integration of incoming components and introspect the service/solution to provide enough feedback to validate the service matches the system modeller's specification. Tools and more tools!

Design Concepts

 * Use Cases and Generated Requirements.
 * Design Concept - Service : providing a theme and focus for multi-agent orchestration.
 * Design Concept - Orchestration Platform Prototype - moving towards a useful and versatile basic platform for delivering multi-robot services.

Links & Resources

 * Other Projects
 * Research Survey
 * Conferences & Journals