Train & Creation Wizard

Train Lifecycle Diagram. In general, we have two state types in our workflow. The first (yellow) states represent the states of the Train Class in the App Store. If a researcher requests a Train, the Train is instantiated and is following the states in the lower part of the figure. The lower part represents the actual Train circulation in our Station network.

Overview

In general, Trains contain specific analysis tasks, which are executed at distributed data nodes – the Stations. In order to complete their task, a Train moves from Station to Station to consume data as an outcome of the executed analytical task. The Train requester, e.g., a researcher selects the Station sequence to be visited. The results are incrementally generated and can be anything based on the Train code. For example, the result set can contain data on an aggregated level, e.g., number showing a cohort size, which has no relationship to individual patient data of the input level, or updated parameters of a statistical model, such as a regression model that is incrementally fitted from Station to Station.

Trains can have several states in their lifecycle, which adds transparency about the state-flow of a Train itself and provides information about the Train status to the users. Possible states are illustrated in Figure above.
First, a Train Class is created and stored in a so-called App Store (Train Class Repository) after the domain community examined the Train to prohibit malicious code executions at the Stations. If a researcher wants to conduct a data study, the researcher selects a suitable Train Class and a new Train Instance is created. According to our workflow definition, a Train can be in an idle state if it waits in the queue for being pulled by a Station. After the transmission, the Train is in the running state if the Station executes it. If the Train execution at a Station was successful, the Train is pushed back to the repository and the workflow starts again according to the selected Station sequence. In unsuccessful cases, the Train is also pushed back but for debugging purposes and the sequence stops.
Further, the statechart above includes corresponding states if the Station sequence was processed successfully or an error occurred. Finally, the Train requester is able to inspect the results. The advantage is that at any point in time, the Train requester is aware of the current state, which is a leverage for the usability of such a network.

Train Creation Wizard

Will be released soon!