Orchestration/Design Goals

= Design Goals =

Some goals that are worth keeping in mind when designing. These are of a less practical or technical nature, but should influence the decisions made.

DG3: Jobs and resources

We are seeking a distributed way of working with the multiple agents that resembles an ecosystem in which jobs and resources are constantly bidded for, assigned, allocated and requested. This is rather typical of any multi-agent system. Do background research, look for methods, software and integrations which best align with our other design goals and use case requirements.

DG4: Find best practices for harnessing the input of humans to create and embed knowledge into the orchestration

Given the complex nature of orchestration, utilising humans to influence the creation and customisation, the embedding of knowledge and rules for both practical reasoning and planning for the orchestration of a solution is desirable and also our primary goal. This will lead to far more flexible solutions than those micro-managed (refer to DG2) and robust than those initially relying on arbitrary learning layers to cope with the complexity involved. The target group of humans should not necessarily be developers - preferably they should be users of the system.

DG5: Put the decision making where the expert is.

Any system design should ensure that any decision making is placed where it has the best possible resources to make that decision. A good example of this practice is in assigning tasks to a robot. Quite often assignation of that task is performed by a higher level process, whereas in fact the best possible process to be making that decision is the robot itself. If a robot is designated a task involving delivery of an object, it is the robot that understands whether it can accommodate the required payload weight, size, handling. Not the process that is assigning the task (the developer of which is usually fairly ignorant about payload details). This gets a little more complicated if there is bidding by multiple agents for a task, but in this case, each agent should still be required to put forth its case to its suitability for the task according to its own decision making ability. This particular process is sometimes referred to as agent introspection.

DG6: Execution of any orchestration strategy should have monitoring processes

The orchestration itself should have means to introspect and analyse its workflows to ascertain when goals are being met and when critical failures arise. A desirable feature (though not immediately essential) is for it to have the ability to re-plan around critical failures.

DG7: Incorporate interactive concert clients (web app/android agents)

When its a human on the other end, these clients should be accommodated as interactive clients in the system - while most others are fixed, and either pre-connected or invited into the system, interactive clients engage and disengage according to their user's will. In addition, a regular client's choice of application is chosen by the orchestration, while interactive clients are subject to the idea of roles - when connecting they can choose from a role the concert assigns and select the application they desire.

DG8: Retask clients based on the urgency of job

Some services in solution may have higher priority jobs compare to others. For example, fire watcher job in building manager would have higher priority than floor cleaning job.

DG9: Utilise the appable robot

The appable robot has already been established as our public interface to robot clients and is equally suitable for both embedded devices and pc served applications. The important aspect of this is that each concert client has the potential to retask itself by running a single robot app at any point in time (or alternatively be idle). The list of applications that a concert client can run is a dynamic entity that can be utilised by the orchestration level. Note that while the appable framework itself is fairly well defined, what it exposes for interaction with the orchestration is still open for design.

Blackboard
Any random babbling or even better, ideas...please add here.