“Workflows and Choreographer” in the FASYS project.

As it was explained in previous posts, a “Health Continuous Vigilance System” is been developed inside the FASyS Project. It provides a workable solution in order to improve the current healthcare system in the factories of machining, handling and assembly operations. With such system, it’s possible to obtain a more continuous monitoring of the worker, improving his own health and making the factory safer and healthier, by increasing the number of variables obtained from the environment of the worker, from personal parameters, and by combining them with the medical knowledge and the actuation protocols.

One of the main modules of this Health Continuous Vigilance System is the Response Medical Center (RMC) where the main tool is the NOMHAD application whose first version that is all but finished (not including environmental data). Once the information has been monitored and classified, the next point is focused on the intervention. With the aim of representing prevention protocols for this intervention, workflows are developed. Given the workers singularity, the adaptation of the prevention protocols is needed for each one of them. In this way, the elimination of the occupational hazard is much more effective.

In order to illustrate graphically the action to perform and the standards describing the flow followed by actions, it is possible to use Workflows. They are a formalization of the process to be automated. Some “workflow languages” can be executed automatically. This is known as a workflow interpretation. The automatic interpretation of a workflow is done by a “workflow engine”, which can complete the actions explained in a workflow, in the order and with the derivation rules specified in it. Workflows can be employed by people who are not experts in programming for the health area. For that reason and thanks to these modules, health professionals are able to design and modify the protocols to be executed automatically. And that’s the reason of the importance of Workflows in the FASyS Project. In order to give support to this important piece a lot of already existent workflow languages and workflow engines has been studied and tested, but we finally decide built the ours: TPA and TPA-engine.

Coming back to the process of gathering information about the worker (either personal parameter or environmental data) it should be noted that it’s necessary to interconnect sensors and services in a fault tolerance and decentralized way. This process, complex and highly interconnected, can be solved using a “Choreography of Services”. This means that the “choreographied” processes are independent and can communicate each other to define execution flows. This model makes easier the connection and disconnection of services dynamically, and at the same time it is capable of using different kind of sensors and configurations. This approach is shown in next figure:

FASyS Architecture

The use of “choreography” to interconnect services requires also the use of a common exchange language to allow the services to understand each other. This can be performed by an architecture which includes a Semantic layer in the Choreographer. The reason to do that is to improve the intercommunication among sensors, actuators and services of the system. From the programmer’s view, “choreography”·is similar to SOA but with some important differences: services are not discovered but known from a defined list, besides the code is quite light (thought for devices with very small computing performances), and so on.

The ontologies are a solution to describe concepts formally. Concretely, an ontology is a formal and explicit specification of a shared conceptualization. It provides a common vocabulary that can be used to model the kind of objects and/or concepts and its properties and relations. The “Ontologies Reasoners” are software applications allowing the semantic seek in the ontologic description. Using this technology, it is possible to describe semantically the sensors and data services, giving them the ability of having a more complete understanding of the collected data and the services actions.

The use of services of Ontologies and Reasoning Systems to describe the data coming from the sensors, makes possible to get a more precise interpretation and to detect automatically the sensors and services available at any time.

Finally, referring to figure, a “Services Orchestrator” is also included in the architecture and moreover. “Orchestrator” is an automata engine that is connected to the Choreographer which accepts the use of Workflows relating different services linked by the “Choreographer”.

Although is not shown in the above figure, a “Process Mining” module has also been added. The main objective of this Process Mining Module is to build, from all the events data gathered about a worker, the real process followed during an activity (this process could be either the consequence of a workflow assigned by medical professional or the one in working with dangerous machine. In such way the current process can be compared against, depending on the case, the one established by the medical staff or the one he use to do. Therefore, we can detect either the break of medical workflow, or an anomalous conduct in worker habits that could be the visible effect of an internal (physical or psychological) problem.