This paper presents a solution to the Incremental Recompilation Laboratory Workflows Case at the TTC 2021 using the .NET Modeling Framework (NMF). This solution is able to derive an incremental change propagation almost entirely in an implicit manner. Section 2 gives a brief overview on how NMF Expressions and NMF Synchronizations work. Section 3 explains the The transformation of high-level process models to low- actual solution. Section 4 evaluates the solution against level jobs actually executed on machines is a common the reference solution. Finally, Section 5 concludes the problem not only in laboratory automation but also in paper. other domains such as smart production. In these domains, it is desirable to adapt an executed process in case of errors or at least avoid wasting resources if it is clear 2. NMF Expressions and NMF that the complete workflow cannot be performed com- Synchronizations pletely. As there are typically a lot of things that could go wrong, it is desirable to design a transformation system NMF Expressions [2] is an incrementalization system in such a way that an incremental change propagation integrated into the C# language. It takes expressions of can be inferred, i.e. does not have to be specified by the functions and automatically and implicitly derives an developer. incremental change propagation algorithm. This works To assess to what degree current model transformation by setting up a dynamic dependency graph that keeps tools are able to infer an incremental change propagation track of the models' state and is adapted when necessary. in such scenarios, the Transformation Tool Contest1 2021 The incrementalization system is extensible and supports hosts a case for incremental recompilation of laboratory large parts of the Standard Query Operators (SQO2). automation workflows. This paper presents a solution NMF Synchronizations is a model synchronization apto this case using the .NET Modeling Framework (NMF) proach based on the algebraic theory of synchronization [1]. blocks. Synchronization blocks are a formal tool to run NMF is a framework built to support model-driven en- model transformations in an incremental (and bidirecgineering, incremental model analyses and incremental tional) way [4]. They combine a slightly modified notion model transformations. In particular, NMF Expressions of lenses [5] with incrementalization systems. Model [2] is an incrementalization system able to incremen- properties and methods are considered morphisms betalize arbitrary function expressions and NMF Synchro- tween objects of a category that are set-theoretic products nizations [3, 4] is an incremental model transformation of a type (a set of instances) and a global state space Ω . approach. Using both tools in combination, it is possi- A (well-behaved) in-model lens : ˓→ between ble to solve the incremental laboratory workflows case types and consists of a side-efect free Get morin a declarative manner such that the required change phism ↗∈ (, ) (that does not change the propagations can be derived mostly implicitly. global state) and a morphism ↘∈ ( × , ) The remainder of this paper is structured as follows: called the Put function that satisfy the following conditions for all ∈ , ∈ and ∈ Ω :
↘ (, ↗ ()) = (, ) ↗ ( ↘ (, , )) = (, ˜) for some ˜ ∈ Ω .
2http://msdn.microsoft.com/en-us/library/bb394939.aspx; SQO is a set of language-independent standard APIs for queries, specifically defined for the .NET platform. Φ− Φ−
A schematic overview of a synchronization block is depicted in Figure 1. The usage of lenses allows these declarations to be enforced automatically and in both directions, if required. The engine computes the value that the right selector should have and enforces it using the Put operation. Similarly, a multi-valued synchronization block is a synchronization block where the lenses and are typed with collections of and , for example : ˓→ * and : ˓→ * where stars denote Kleene closures.
Synchronization blocks have been implemented in
NMF Synchronizations, an internal DSL hosted by C#
[
The first condition is a direct translation of the orig- 1 public void InitializeContext(IEnumerableExpression<ISample> inal PutGet law. Meanwhile, the second line is a bit 2 contexsta.mDpalteas.,AdIdS(yn_cphlraotneiszKaetyi,onsCaomnptleexst context) { weaker than the original GetPut law because the global 3 .ChunkIndexed( 8, ( samples, column ) => new state may have changed. In particular, we allow the Put 4 ProcesssaCmoplluemsn.(Secloelcutm(n,tuple => new ProcessWell( function to change the global state. tuple.Item2 % 96, tuple.Item1 ) ) ) )
A (single-valued) synchronization block is an 8- 5 .Chunk($"1P2l,at(e{cpollautmenIsn,depxl+a1t:e0I0n}d"e,xc)ol=u>mnnsew) P)rocessPlate( tuple (, , , , Φ − , Φ − , , ) that declares a 6 .AsNotifiable() ); synchronization action given a pair (, ) ∈ Φ − : 78 co.nCtheuxntk.IDnadteax.eAdd(d(16_,tu(bessaKmepyl,ess,amtpulbeesIndex ) => new Tubes( $ ∼= of corresponding elements in a base isomor- "Tube{tubeIndex+1:00}", phism Φ − . For each such tuple in states (, ), 9 samplest.uSpellee.cItt(emt2up%le16=,>tnuepwleP.rIotceems1sW)el)l() ) the synchronization block specifies that the elements 10 .AsNotifiable()); ( (, ), ↗ (, )) ∈ × gained by the lenses 11 } and are isomorphic with respect to Φ − .
Listing 1: Setting up the mapping of samples to plates
and wells
This flexibility makes it possible to reuse the
specification of a transformation for a broad range of diferent
use cases. Furthermore, the fact that NMF
Synchronizations is an internal language means that a wide range
of advantages from mainstream languages, most notably
modularity and tool support, can be inherited [
This section describes key aspects of our solution. First, we describe how samples are chunked into plates and columns in Section 3.1. Next, we give a high-level overview of the actual synchronization in Section 3.2. Sections 3.3–?? describe how the diferent high-level protocol steps are synchronized. Section 3.6 explains the synchronization of the Next reference and finally, Section 3.7 shows how the synchronization is initiated.
As a first step, the samples to process are grouped into plates and columns. Each column consists of 8 wells that can be pipetted at the same time. This is done using the Chunk operation recently built into NMF. This comes in two versions, Chunk and ChunkIndexed where the latter also keeps the original index in the original collection. The code for calculating the assignments of samples to plates, columns and tubes is depicted in Listing 1. This listing shows how to register a collection of samples with a synchronization context. That is, because the assignment of plates is needed in many places throughout the synchronization, we put it as context.
The input type IEnumerable<ISample> used in Line 1 of Listing 1 denotes an incrementalizable collection of samples. NMF essentially implements the Standard Query Operators of C# and a few more operators on 2 3 4 5 6 7 8 public class AddReagentToJobsRule : SynchronizationRule<
AddReagent, JobsOfProtocolStep> { public override void DeclareSynchronization() { MarkInstantiatingFor( SyncRule<ProtocolStepToJobsRule>() ); SynchronizeManyLeftToRightOnly(
SyncRule<AddReagentLiquidTransferToLiquidTransfer>(), ( step, context ) => GetPlates( context ) .SelectMany(p => p.Columns, (plate, column) => new
AddReagentLiquidTransfer(column, plate, step)) .Where(transfer => transfer.Column.AnyValidSample.
Value), ( jobsOfStep, _ ) => jobsOfStep.Jobs.OfType<IJob,
LiquidTransferJob>() ); } } Listing 3: Synchronizing the jobs for an AddReagent protocol step of the requested assay should be synchronized with the job collections in the low-level model. For this, we use a custom collection implementation that essentially groups the low-level jobs of the resulting job collection by name. This needs access to the transformation context as it will store information such as the afected samples of a job. The four calls to SynchronizeManyLeftToRightOnly basically define collection-valued unidirectional synchronization blocks that are only enforced from the left to the right.
top of this interface in order to derive an incremental change propagation for a given query. That is, the system allows developers to obtain incremental updates of the results upon changes of the input models, such as adding a sample.
Lines 3–5 in Listing 1 calculate columns as chunks of samples. These columns are then chunked into microplates. Line 6 forces the incrementalization of this collection. The idea of this order as opposed to chunking the samples into plates and then further into columns is to allow NMF to rebalance samples between columns and then rebalance columns between plates. However, we did not specify a balancing strategy and thus, NMF will not try to rebalance the chunks. Similar, lines 8–9 calculate the collection of tube runners from diferent chunks of the input samples.
The actual high-level process steps are translated using separate synchronization rules. That is, we synchronize a protocol step with the jobs implementing this protocol step. The approach to transform the other types of highlevel jobs is conceptually similar, although the diferent complexity of the job types leads to a diferent complexity of the synchronization rules required. The synchronization rule for the synchronization of AddReagent is depicted in Listing 3.
Line 3 marks the synchronization rule as instanti3.2. The model synchronization ating for ProtocolStepToJobsRule, which means that the synchronization rule is used when the The actual model synchronization is split into several ProtocolStepToJobsRule is executed with an Addsynchronization blocks that act as isomorphisms. Each Reagent protocol step. Lines 4–9 denote the synchrosynchronization rule defines a list of synchronization nization block that computes the elements from which blocks that define what data should be synchronized. to create the jobs, using a dedicated class to represent The entry point synchronization rule, depicted in Listing the request for a liquid transfer. The query calculates all 2, synchronizes an overall high-level job request with a columns of all plates that have at least any valid (i.e., not low-level job collection. In this listing, Lines 3–4 denote failed) sample. that the reagents are mapped to troughs and lines 5– Because the latter needs to be calculated incremen10 denote that that tube runners should be created to tally for each ProcessColumn, the calculation (and its host the samples as well as microplates for processing. incrementalization) is separated into a static function For the tubes and the microplates, we consume a second (see Listing 4). parameter in the lens to access the plate collections stored The reason to separate the logic into an in the context (cf. Listing 1). ObservingFunc instance here is that the incre
In Lines 11–13 of Listing 2, we define that the steps 2 3 1 2 3 4 5 mentalization of a method in NMF involves some reflection and takes a bit of time while applying it to a particular element is rather cheap. Using a static instance essentially caches the incrementalization and applies it to multiple instances. For this reason, although supported by NMF, nested queries are currently rather slow and hence we refrain from using the C# query 1 private static Tubes GetSourceTube( ITransformationContext syntax in the mappings such as Listing 3. 2 returcnonGteetxTtu,bePsr(occeosnstCeoxltum)n column ) {
The child synchronization rule AddReagentLiquid- 3 .AsEnumerable() TransferToLiquidTransfer defines how the in- 45 .F.iArssEtnOurmDeerfaabullet(() t => t.Samples stances of this intermediate class are transformed into a 6 .Any( s => column.Samples low-level job as depicted in Listing 5. Line 3 defines that 78 ..AAsnEyn(usm2er=a>bles.()Sample == s2.Sample ) ) ); the source of the liquid transfer should be synchronized 9 } with the trough created for the reagent. Line 4 specifies Listing 7: Calculating the rube runner for a given column that the reagent should be pipetted into the microplate of a processing plate created for the processing request. In Lines 5–9, the synchronization block denotes which tips exactly need to be The solution now is to break out of the incrementalcreated. We use an intermediate class and a custom col- ization monad explicitly and calculate the source tube lection again in Line 9 in order to control that a tip liquid runner only once as depicted in Listing 7: We explicitly transfer is only removed when it is still planned. Lines call the AsEnumerable method here in order to instruct 10–12 specify that the samples created for this liquid the compiler to actually compile the lambda expressions transfer are stored inside the transformation context. used to calculate the tube runner. This, however, breaks
The synchronization rule AddReagentTipToTip- the support of rebalancing the chunks making up the Transfer depicted in Listing 6 specifies the transfor- columns and plates. 6 7 } } public class AddReagentTipToTipTransfer :
SynchronizationRule<AddReagentTip, ITipLiquidTransfer > { public override void DeclareSynchronization() { SynchronizeLeftToRightOnly( well => well.AddReagent.
Volume, transfer => transfer.Volume ); SynchronizeLeftToRightOnly( well => well.TargetWell.Well,
transfer => transfer.TargetCavityIndex ); SynchronizeRightToLeftOnly( well => IsSampleFailed( well.
TargetWell.Sample ), transfer => transfer.Status == JobStatus.Failed );
AddReagentTipToTipTransfer rule mation of tip liquid transfers. Lines 3–4 synchronize the volumes and the target cavity (the source cavity is always 0 for a trough).
The last synchronization block in line 5 specifies that the failure of the tip transfer should be synchronized back to the high-level job request model.
The synchronization of DistributeSample elements works exactly like the synchronization of AddReagent with one important exception: While the source labware of an AddReagent is accessible easily via the transformation trace from the reagent, this is unfortunately not as easy for DistributeSample.
As a reason, the current design of the solution has no direct connection between a column of a processing microplate and the tube runner that holds the samples. First, we created an approach that would calculate the mapping incrementally, but this turned out to be very resource-intensive both in terms of time and memory.
The synchronization of Wash steps and Incubate steps is very similar, because both steps (as many in lab automation) operate on entire microplates. The protocol step needs to be instantiated for each microplate used for sample processing.
The synchronization rule templates for protocol steps operating on a single microplate is depicted in List- 3.6. Synchronization of the Next ing 8. There are two rule templates, one for synchro- reference nizing a protocol step with a collection of low-level In order for the scheduler to be able to actually schedule jobs, the other for actually synchronizing the proto- the low-level jobs, the base class for jobs keeps a reference col step for a given microplate into a given job. The to the next and previous jobs. That is, the scheduler may MicroplateProtocolStepRule class marks the rule only schedule a job if all previous jobs are completed and as instantiating and registers the calls to the child rule. in the opposite direction, the job is a prerequisite for all The template for the latter, MicroplateJobRule, reg- next jobs. isters afected samples, sets the samples to failed (using To aid this situation, we use a utility class called another lens called AreAllFailed in Line 25) and syn- CollectionBinding that essentially enforces the synchronizes the target microplate. As the target metamodel chronization of elements between an incrementalizable does not use a shared base class for jobs operating on source collection (typically a query) and a target colmicroplates, the rule template uses an abstract property lection that should be adapted. The implementation is public class WashToJobsRule : MicroplateProtocolStepRule<
Wash, WashToWashJob, WashJob> {} public class WashToWashJob : MicroplateJobRule<Wash,
WashJob> { protected override Expression<Func<WashJob, IMicroplate>>
MicroplateProperty => wash => wash.Microplate; public override void DeclareSynchronization() { base.DeclareSynchronization(); SynchronizeManyLeftToRightOnly( tuple => tuple.Item2.Columns.SelectMany( c => c.Samples.
Where( s => s.Sample.State != SampleState.Error ).
Select( s => s.Well ) ), wash => wash.Cavities ); } }
such that instance rules have to specify the property used to store the microplate.
The instantiation of the rule templates for Wash elements is depicted in Listing 9. Since the rule to synchronize Wash protocol steps is suficiently described using the synchronization template, we do not need to provide any further specification other than the type parameters to be used, including a reference to the child rule. Unfortunately, the C# compiler is not (yet?) able to infer the type parameters TProtocol and TJob, so they must be specified explicitly.
For the synchronization of a Wash in conjunction with a specific processing plate, we need to specify the property holding the microplate (in Line 4) and handle the additional reference to the cavities that should be washed.
For this, we need to override the declaration of the synchronization rule. Because we do want to inherit the declaration of the template, we need to call the base declaration in line 6. Then, we add the synchronization of the cavities in lines 7–9.
The synchronization of Incubate protocol steps works in the same way, except that the child rule extends the template with synchronization blocks for temperature and duration. 1 CollectionBinding.Create( 2 _nextJobs.Jobs.Where( j => ProtocolSynchronization.
GetAffectedSamples( _context, j ).Intersect( samples ).Any() ), 3 item.Next ) Listing 10: Binding the next low-level jobs to the jobs of the next job collection that afect the same samples
Before we describe the results in terms of performance, keep in mind that the reference solution is a solution tailored manually and explicitly for the given types of changes, without any incrementalization system or alike.
Therefore, it is hard to beat it in terms of performance and the strengths of our solution are rather in the declarativeness and large variety of supported change types.
To evaluate the solution in terms of performance, we have run the benchmark on a system equipped with a Intel Core i7-8850H CPU clocked at 2.6Ghz and 32GB RAM, running Windows 10. The results are discussed in the remainder of this section. 3.7. Starting the synchronization depicted in Listing 10. The query calculates the jobs for which the set of afected samples intersects the affected samples of the current job. The return value is an instance of the IDisposable interface, the typical inter- 4.1. Scaling Samples face in .NET to dispose objects. In this case, the binding is stopped when disposed. Since NMF supports bidirec- The results in terms of time to execute the initial transtional references, only one direction of the the association formation for the scaling samples scenario are depicted has to be set manually, the other is set automatically by in Figure 2. In this scenario, the diferent models repreNMF. sent loads of 8 samples (size 1) to 256 samples (size 32),
Unfortunately, the management of the collection bind- applied to a simple ELISA assay model. The results show ing currently has to be done manually by handling change that whereas the time for the reference solution is essenevents of the jobs created for a job collection. tially constant at around 50ms, the initial time for the NMF solution grows worse than linear, it is more like quadratic.
To run the solution, we create a new context for the model synchronization, initialize the samples and start the model synchronization in the direction LeftToRight with change propagation in both directions. 1 _context = new SynchronizationContext( _synchronization, 2 SynchronizationDirection.LeftToRight, 3 ChangePropagationMode.TwoWay ); 4 _synchronization.InitializeContext( _jobRequest.Samples,
_context ); 5 _synchronization.Synchronize( ref _jobRequest, ref
_jobCollection, _context );
The strongest point of the presented solution is that the change propagation can be inherited mostly from a declarative specification. As a consequence, essentially all types of changes are supported, not just the change types executed by the benchmark framework. This means that new types of error handling do not necessarily have an efect on the transformation but they are supported by default. The declarative specification, however, keeps the understandability of the solution at a good level. The attendees of TTC will judge on the understandability compared to the reference solution.
In addition to the inherited change propagation, the solution also means that no changes to the metamodel code are necessary and the model representation can be reused independently of the transformation. 104 ]s [m103 e m i T 102
We profiled the NMF solution. The results show that much of the time is lost because NMF Synchronizations executes the incrementalization of the queries used to specify the synchronizations over and over again instead of reusing it. Furthermore, the collection binding depicted in Listing 10 also requires the system to be incrementalized over and over again. We expect that the performance gap could be reduced, if the frameworks can be adapted to cache the incrementalization properly.
The results for propagating the state changes of lowlevel elements are depicted in Figure 3. This includes both changing the sample state and potentially removing low1 2 4
Tool ATL_Incremental NMF Reference ttc2021_iworkflows_YAMTL 8 16 32 64 128 256 512 1024
Model level job elements as they have become obsolete (since takes longer for smaller models up to some point. This all processed samples failed). Although the NMF solution is because the benchmark framework uses Pythons is slower, it is still within few milliseconds even for the subprocess.POpen to spawn the processes for the largest models considered. model sizes and they can make use of JIT optimizations of earlier runs. Again, the propagation of the changes 4.2. Scaling the Assay happens in a few milliseconds, both for NMF and the reference solution, the reference solution being slightly In the scale assay scenario, all model sizes use 96 samples, faster. but the number of protocol steps varies: Whereas the smallest model (size 1) uses a simplified ELISA assay 4.3. New samples model with 8 steps, the largest model uses 32 repetitions (256 protocol steps in total). The execution time for the The results for the initial transformation in the new saminitial transformation is depicted in Figure 4. The runtime ples scenario are depicted in Figure 6. Not very surprisof the NMF solution is again quadratic in the size of the ingly, they are similar to the scaling samples case because model while the reference solution remains fast. the parameters for the initial model are exactly the same. 103
The results for updates are depicted in Figure 5. The results look awkward because the change propagation
The diference to the scaling samples scenario is that new samples are introduced during the runtime of the 3 × 100 ]2 × 100 s m [ e m i T 100 103 ]s m [ e m i T 100 benchmark. The results for propagating these changes are depicted in Figure 7. Still, the changes are propagated within a few milliseconds, but this time this is much slower than in the other two scenarios, in line with the performance issues in the initial transformation.
The solution has shown that it is possible to derive an incremental change propagation for most of the transformation. Only for smaller parts such as the synchronization of the next reference, manual code is necessary. The evaluation shows that the performance is good, although it cannot keep up with the reference solution. In exchange, the solution supports much more types of changes. However, the solution also shows a performance problem caused by the current inability of NMF to cache the query incrementalization properly.