Software Engineering Design
Patterns for Machine Learning
Applications
Hironori Washizaki
Waseda University / National Institute of Informatics / SYSTEM INFORMATION / eXmotion

Foutse Khomh
Polytechnique Montréal

Yann-Gaël Guéhéneuc
Concordia University

Hironori Takeuchi
Musashi University

Naotake Natori
Aisin Corporation

Takuo Doi
Lifematics Inc.

Satoshi Okuda
Japan Advanced Institute of Science and Technology

Abstract—
Practitioners and researchers study best practices to design machine learning (ML) application
systems and software to address quality and constraint problems. Such practices are often
formalized as design patterns. In this study, a multi-vocal literature review identified 15 software
engineering design patterns for ML applications. A questionnaire survey inquired about ML
developers’ use of the ML design patterns to validate them in practice. 118 ML developers
responded to our survey. Results show that developers were unfamiliar with most of thepatterns, although there are several major patterns already used by 20+% of the respondents.
For all patterns, most of the respondents would consider using them in future designs. As the
respondents became more consistent in their approach to design problems by reuse, the patternusage ratio increased. These findings suggest that there are opportunities to increase thepatterns’ adoption in practice by raising awareness of such patterns within the community.

T HE POPULARITY OF machine learning (ML)techniques has increased in recent years. ML isused in many domains, including cyber security,
the internet of things (IoT), and autonomous cars.
ML techniques rely on mathematics and software

Computerengineering. The former generates algorithms,
develops capabilities to learn from input data,and produces representative models. The latter is
employed for implementation and performance.
Many works have investigated the mathematics and computer science on which the ML tech-

Published by the IEEE Computer Society© 2022 IEEE1

Department Headniques are built, but few have examined implementation. This situation raises concerns such as
the complexity of ML techniques and the qualityof the available implementations, which software
defects may negatively impact. These concerns
should be alleviated if developers could demonstrate the software quality of their implementations. Consequently, researchers and practitioners
study best practices to design ML application systems and software to address issues with software
complexity and the quality of ML techniques.
Such practices are often formalized as design
patterns. These patterns encapsulate reusable solutions to commonly occurring problems within
ML application design.
There are surveys and case studies on practices and practitioners’ insights on ML systems
development in general [1], [2], [3]. However,none of them focus on the use of concrete ML
design patterns.
Herein we report the results of a multivocal literature review of design patterns for ML.
Based on the results, we report on developers’
perceptions to validate these patterns in practice.
Preliminary literature review results and preliminary study on practitioners’ perceptions were
presented at [4], [5]. In this paper, we examined
all patterns and conducted a large-scale in-depth
study on developers’ perceptions. We also describe one major ML design pattern to show how
the ML design patterns are documented and used
for resolving design problems.

ML Design Patterns in the Literature
We define “software engineering patterns for
ML application systems and software design”(hereafter, ”ML design patterns”) as any patterns
that include design structure directly or address
design concerns of ML software systems indirectly. We performed a multivocal literature
review of both academic and gray literature tocollect them.
For the academic literature, we chose Engineering Village, which is a search platformthat provides access to 12 engineering document databases, such as Ei Compendex and Inspec. Engineering Village can search all recognized scholarly engineering journals, conferences,and workshop proceedings with a unique search
query. On August 14, 2019, we designed and2used the following query specifying “pattern” aswell as keywords related to patterns to search for
documents addressing ML design practice. Basedon the broad definition of ML design patterns inthis paper, we included relevant keywords suchas “implementation pattern” and “architecture
pattern” since they may handle design concerns
indirectly.
((((system) OR (software)) AND (machinelearning) AND ((implementation
pattern) OR (pattern) OR (architecture pattern) OR (design
pattern) OR (anti-pattern) OR (recipe) OR (workflow) OR (practice) OR (issue) OR (template))) WN ALL) + ((cpx OR ins OR kna) WN DB) AND (({ca}OR {ja} OR {ip} OR {ch}) WN DT).

For the gray literature, we used a Google
search on August 16, 2019. The query was thesame as that for the academic literature:(system OR software) "machine learning" (pattern OR "implementation pattern"
OR "architecture pattern" OR "design
pattern" OR anti-pattern OR recipe OR
workflow OR practice OR issue OR
template)and:"machine implementation pattern" OR "architecture pattern" OR "design
pattern" OR anti-pattern OR recipe OR
workflow OR practice OR issue OR
template.

We retrieved 32 scholarly documents and 48
gray literature documents. Two of the authors
examined whether each document should be included in our review using the following criteria:
Documents written in English addressing concrete software-engineering patterns or practices
to design ML application systems and software
should be included. Documents focusing on design of ML techniques and algorithms should
be excluded. This process identified 19 scholarly
documents and 19 gray documents. All the data
are available at [6]. Among these documents,
there was no paper published at PLoP series thatare conferences on patterns and pattern languages,
although PLoP series proceedings published at
ACM have been included in the search using theEngineering Village.
Figure 1 shows the trend in the number of
documents related to the design of ML application systems in the past decade. ML application

Computersystems have recently become popular due to thepromotion of artificial intelligence (AI). Since
2008, academic and gray documents have discussed good practices of ML application design.
10
9
8
7
6
5

Scholarly

4
3
2

Gray

1
0
2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

Figure 1. Number of documents per year

Overview and Classification of ML
Design Patterns
Two of the authors each read half of the
documents. Each author extracted patterns independently. Then one of the authors checked eachpattern by reading the entire document to determine whether the pattern pertained to software
engineering design practices for ML systems. The
extraction process identified 69 patterns. However, the checking process reduced this to 33 patterns related to the architecture and design of ML
systems. Finally, three industrial ML developers
reviewed the 33 candidates from the viewpoint ofpractical usefulness. During the review process,any disagreement has been resolved by discussion. They identified only 15 ML design patterns(Table 1). The remaining 18 candidates were not
identified as ML design patterns due to theirunclear descriptions or shortage of information
supporting their usefulness.
Not all of the identified ML design patterns
are well-documented in a standard pattern format,
which includes a clear problem statement andthe corresponding solution descriptions. Thus, we
described most of these ML design patterns in astandard pattern format so that practitioners caneasily (re)use them in their contexts [7], [8], [9].
Through our literature review and reading of
the documents, we noted various characteristics
that could help classify ML design patterns.
Figure 2 shows an abstract structural overview
of ML applications consisting of models, data,and infrastructures. Based on the overview, weMarch 2022

classified these ML design patterns into three
categories according to their scopes (Table 2):• P1 –P6 are ML system topology patterns thatdefine the entire system architecture.
• P7 –P10 are ML system programming patterns
that define the design of a particular component.
• P11 –P15 are ML model operation patterns that
focus on ML models.
Topology patterns can be regarded as architecture patterns that handle unique architectural
rules specific to ML systems, while programming
patterns can be seen as design patterns that are
relatively less specific to ML. Nevertheless, theprogramming patterns still address some design
characteristics of ML software in addition to thegeneral design characteristics. Model operation
patterns are all specific to ML models.
Furthermore, any design pattern should address one or more quality attributes that areassociated with design problems. For ML design
patterns, we assumed that the following productquality attributes defined in ISO/IEC 25010:2011
as well as model and prediction quality attributes
can be addressed.

• System and software product quality attributes:
Functional suitability, performance efficiency(denoted as ‘E’ in the table), compatibility (C),usability, reliability (R), security (S), maintainability (M), and, portability (P)• ML model and prediction quality attributes:
Model robustness (Mr), model explainability(Me), prediction accuracy (Pa), and, prediction
fairness
One of the authors analyzed the quality attributes by reading problems and solutions descriptions of the 15 ML design patterns and identifying related specific descriptions or keywords(e.g., “If . . . has data dependency, it is difficult
to localize the erroneous part” implies maintainability). Then, four of the authors reviewed andconfirmed the result. Many ML design patterns
address maintainability (Table 2). Most operation
patterns address model and prediction quality
attributes. Since no ML design pattern addresses
usability and prediction fairness, these attributes
are excluded from the table.

3

Department Head

Table 1. Extracted ML design patterns
ID
P1

Pattern Name
Different Workloads in
Different Computing Environments [8], [10]P2DistinguishBusiness
Logic from ML Models[7], [11]P3ML Gateway Routing Architecture [11]P4Microservice Architecture
for ML [7], [12]P5

Lambda Architecture forML [9], [13]P6

Kappa Architecture forML [9], [14]It is necessary to deal with huge amount ofdata with less code resource.

P7

Data Lake for ML [7],
[13]

P8

Separation of Concernsand Modularization of ML
Components [2]Encapsulate ML Models
withinRule-base
Safeguards [8], [15]We cannot foresee the kind of analyses thatwill be performed on the data and whichframeworks will be used to perform suchanalyses.
ML applications must accommodate regularand frequent changes to their ML components.
ML models are known to be unstable andvulnerable to adversarial attacks, noise indata, and data drift overtime.

P9

4

Problem (excerpt)
It is necessary to separate and quickly
change the ML data workload and stabilize the training workload to maximize efficiency.
The overall business logic should be isolated
as much as possible from the ML models
so that they can be changed/overridden asnecessary without impacting the rest of thebusiness logic.
When a client uses multiple services, it canbe difficult to set up and manage individual
endpoints for each service.
ML applications may be confined to some“known” ML frameworks, missing opportunities for more appropriate frameworks.
Real-time data processing requires scalability, fault tolerance, predictability, and otherqualities. It must be extensible.

P10

Discard PoC Code [16]P11

Parameter-Server Abstraction [16]P12

Data Flows Up, Model
Flows Down [17]Standard ML approaches require centralizing the training data on one machine or ina datacenter.

P13

Secure Aggregation [17]The system needs to communicate and aggregate model updates in a secure, efficient,scalable, and fault-tolerant way.

P14

Deployable Canary Model
[18]

P15

ML Versioning [1], [7],[10], [16]A surrogate ML that approximates the behavior of the best ML model must be built
to provide explainability.
ML models and their different versions maychange the behavior of the overall ML applications.

The code created for Proof of Concept(PoC) often includes code that sacrifices
maintainability for efficient implementationof trial and error, and code that is ultimately
no longer needed.
For distributed learning, widely accepted
abstractions are lacking.

Solution (excerpt)
Physically isolate different workloads toseparate machines. Then optimize the machine configurations and the network usage.
Separate the business logic and the inference engine, loosely coupling the businesslogic and ML-specific dataflows.

Install a gateway before a set of applications, services, or deployments. Use application layer routing requests to the appropriate
instance.
Define consistent input and output data.
Provide well-defined services to use for ML
frameworks.
The batch layer keeps producing views at
every set batch interval while the speed
layer creates the relevant real-time/speed
views. The serving layer orchestrates thequery by querying both the batch and speed
layer, and then merges them.
Support both real-time data processing
and continuous reprocessing with a single
stream processing engine.
Store data, which range from structured to
unstructured, as “raw” as possible into a
data storage.
Decouple at different levels of complexity
from the simplest to the most complex.
Encapsulate functionality provided by ML
models and appropriately deal with the inherent uncertainty of their outcomes in thecontaining system using deterministic andverifiable rules.
Discard the code created for the PoC andrebuild maintainable code based on the findings from the PoC.

Distribute both data and workloads overworker nodes, while the server nodes maintain globally shared parameters, which are
represented as vectors and matrices.
Enable mobile devices to collaboratively
learn a shared prediction model in the cloud
while keeping all the training data on thedevice as federated learning.
Encrypt data from each mobile device incollaborative learning and calculate totals
and averages without individual examination.
Run the explainable inference pipeline inparallel with the primary inference pipeline
to monitor prediction differences.
Record the ML model structure, training
dataset, training system and analytical code
to ensure a reproducible training process
and an inference process.

ComputerTopology patterns
Model
operation
patterns
Programming
patterns

Training data

Input data

Trained model

Prediction

Training
Infrastructure

Serving
Infrastructure

Figure 2. Machine learning system overview andcategories of ML design patterns
Table 2. Classification of ML design patterns
ID
E
C R
S
M
Category: Topology
P1
E
M
P2
M
P3
C
M
P4
C
M
P5
E
R
P6
E
R
Category: Programming
P7
E
C
M
P8
M
P9
R
S
P10
M
Category: Model operation
P11
E
R
P12
E
P13
S
P14
R
M
P15

P

Mr

Me

Pa

P

Mr
Mr

Pa
Pa
Me

Mr

Pa

Engineers’ Perceptions
ML techniques are concrete solutions to practical problems. Hence, ML developers may havealready built a body of knowledge on good design practices of ML development. To clarify
how ML developers perceive existing ML design patterns, we surveyed 600+ software andML developers who participated in an online
seminar on ML design patterns in March 2021.
During the seminar, we explained the conceptof software patterns and introduced the 15 ML
design patterns. Afterwards developers answered
the following questions about reuse practices andpatterns anonymously.

• SQ1. How do you solve and share design
challenges of ML application systems?
• SQ2. (For each pattern) Have you ever referredto this ML design pattern?
Of the 600+ participants, 118 answered ourquestionnaire, which corresponds to a response
rate of approximately 20%. Table 3 summarizes
the survey result of SQ1. Of the 118 respondents,

March 2022

37 (i.e., 31%) organized design patterns and past
design results. Then they reused them to resolve
ML design problems. These are the most mature practices in terms of design solution reuse.
Thirty-one (26%) reused externally documented
patterns but were not organizing patterns or past
results by themselves. These are the second mostmature practices in terms of reuse. 37 (31%) resolved problems in an adhoc way without reusing
patterns. These are the worst practices.
Table 3 also shows numbers of ML design patterns used and the usage ratios, which are calculated by #P atterns used/(#Respondents ×
15). For example, 37 respondents organized patterns, and they answered that in total they had
used 64 patterns. They had the opportunity touse 37 × 15 patterns in total, so their patternusage ratio is 11.5% (= 64/(37 × 15)). As
respondents become more organized in their approach to design problems by reuse, the patternusage ratio increased, as shown in the table, from
6.3% to 10.8% and even to 11.5%. Based on
the result, it is expected that development teams
and organizations will reuse more ML design
patterns to resolve design problems effectively
and efficiently as they become more consistentin their reuse approach.
Figure 3 summarizes the result of SQ2. The
most used patterns were P15 (used by 24% of the
respondents), P4 (21%), and P10 (15%). In termsof the use rate calculated by #U sed/#Knew,
P2 was the most frequently used pattern witha use rate=15/28=0.54. On the other hand, no
respondents actually used P12 or P13 , althoughsome respondents knew of these patterns. Thereis a threat to validity that some participants mightanswer “yes” for patterns that they generally
know and have used the essential part of the patterns’ problems and solutions, while some mightanswer the same but have less understanding (oreven worse, misunderstanding) of the patterns.
Nevertheless, the survey result should help grasp
the general tendency of acceptance of ML design
patterns.
In terms of quality attributes, our previous
survey targeting 300+ developers showed thatmaintainability is most considered among nonfunctional attributes during their ML system developments [5]. And the most used patterns P15 ,P4 , and P10 commonly address maintainability, as

5

Department Head
Table 3. Survey result of SQ1 (N=118)

12

14

12

18

16

19

18

100
80

50

50
68

74

23

28

24

14

20

75

75

58

82

63

70

79

28

81

29

25

18

17

15

13
11

0

15
10

25
10

11
8

18
7

28
15
3

3

24

30

1

0

12
0

P15 P4 P10 P7 P2 P8 P3 P5 P9 P1 P6 P11 P14 P12 P13
Used itNever used it
Knew it

Consider using it
Not consider
Did not know it

Figure 3. Survey result of SQ2 of seminar participants (N=118): Knew and used it, Knew but neverused it, Did not know but will consider using it in the
future, and Did not know and will not consider using itin the future

Example of a Major ML Design PatternHere, we describe one major ML design
pattern and its usage. We selected “DistinguishBusiness Logic from ML Model” (P2 ) since it
was one of the most popular patterns among oursurvey participants. Moreover, it provides a basis

6

Pattern usage ratio
11.5%
10.8%
6.3%
1.5%

Presentation Layer

Logic Layer

Data Layer

UserInterfaceBusiness
Logic

Database

Data
Collection

Data
Processing

Data Lake

Inference
EngineLegendArchitectural Layers
Deployed as ML System

Business Logic Data Flow
ML Runtime Data Flow
ML Development Data Flow

Figure 4. Structure of “Distinguish Business Logicfrom ML Model” pattern [11]for other patterns (such as P7 “Data Lake forML”) by clearly decomposing the ML system
into multiple layers and components. For brevity,
participants, collaborations, implementation, andknown uses are omitted below.
Pattern NameDistinguish Business Logic from ML Model [7](original name “Multi-Layer Architectural Pattern” [11])

33
13

28

25

68

72

20

20

17

50

60
40

25

# Patterns used
64
50
35
3

ML Specific120# Respondents
37
31
37
13

Business
Logic Specificshown in Table 2. Their frequent use may suggestthat they consider them effective for improving
maintainability since maintainability was reported
to be their primary concern.
The developers were unfamiliar with most
ML design patterns, although there were several
major patterns used by 20+% of the respondents.
For all patterns, most respondents indicated thatthey would consider using them in future designs. These findings suggest that the identified
ML design patterns are expected to help resolve
particular problems, and there are opportunities
to utilize existing ML design patterns and realize
more consistent reuse by increasing awareness ofsuch patterns within the ML community.

Real World

Design solution and reuse practice
Organizing patterns and past design results and reusing them
Reusing externally documented patterns
Resolving problems in an adhoc way without patterns
Other (incl. those with little experience in ML system development)

IntentIsolate failures between business logic and ML
learning layer to help developers debug ML application systems easily.
Problem
ML application systems are complex because
their ML components must be (re)trained regularly and have an intrinsic non-deterministic
behavior. Similar to other systems, the business
requirements for these systems and the ML algorithms change over time.
Solution
Define clear APIs between the traditional and ML
components. Place the business and ML components with different responsibilities into threelayers (Fig. 4). Divide data flows into three.
Applicability
It is applicable to any ML application system with
outputs that depend on ML techniques.

ComputerPresentation Layer
Input

Input Data

User Interface(Chatbot UI)
Output

Users

Data Layer

Logic Layer
Business Logic(Chatbot Logic)

Database(Previous Q&A Store)Output Data

Web App
Front-end

Web App
Back-end

Slack

Slack

DB Server(None)

Input Data

Data
SourceDatasets

Data Collection(Dataset)
Datasets

Nagoya Univ.
Conversation
CorpusLegendArchitectural Elements(Example Role as Chatbot)
What

Data Processing
Datasets(Text to Vector Transformer)
NN Modelpre- and postprocessing

Data Lake(Vectorized Corpus)
Word
VectorTensorFlow(Text)

ML Output

ML
Input

Inference Engine(Language Model)

How

Business Logic Data Flow

TensorFlow

Word
VectorNN ModelTensorFlow

ML Runtime Data Flow
ML Development Data Flow

Figure 5. Example of Chatbot system architecture by applying “Distinguish Business Logic from ML Model”

Consequences
Decoupling “traditional” business and ML components allows the ML components to be monitored and adjusted to meet users’ requirements
and changing inputs.
Usage Example
Figure 5 presents an implementation example ofthe pattern in a Slack-based Chatbot system. By
referring to the pattern, the necessary elements
as well as their relationships are easily specified while having clear separation between the
Chatbot service (as the business logic) and theunderlying ML components.

Conclusion
ML application systems are quite popular due
to the recent promotion of AI. To bridge thegap between traditional software systems andML application systems with respect to design,
software-engineering design patterns for ML applications were analyzed via a multivocal literature review and a survey of developers. From the
32 scholarly documents and 48 gray documents
identified in the literature review, 15 ML design

March 2022

patterns were identified. A survey of developers
revealed that there are some major ML design
patterns.
Although the literature review was conducted
in 2019, we believe this is the first step to explore
ML design patterns and build on them to proposerefined patterns. We plan to revise the identified
patterns by sharing them to obtain reviews fromthe public. Since we surveyed the practitioners’
perceptions on the patterns 2-5 years after their
original publications, our survey should reveal themeaningful perceptions. And practitioners may
not be aware of recent patterns such as [19], [20],which have emerged after our literature review.
As our future work, we will continue our survey
by extending the scope of ML design patterns toinclude these recent patterns and ones publishedat some of the PLoP series proceedings, whichwere not included in the original search.
We also plan to create a map of the relationships among these ML design patterns and otherrelated patterns. Furthermore, we will investigate
applications of these ML design patterns in actual
ML systems and software design.

7

Department HeadAcknowledgement

12. D. Smith, “Exploring development patterns in data

The authors would like to thank Mr. Hiromu Uchida for his help. This work was supported by JST-Mirai JPMJMI20B8, JSPS JPJSBP
120209936, and KAKENHI 21KK0179.

science,”https://www.theorylane.com/2017/10/20/

some-development-patterns-in-data-science/, 2017.
13. P. Menon, “Demystifying data lake architecture,”https://www.datasciencecentral.com/profiles/blogs/
demystifying-data-lake-architecture, 2017.
14. V. Tyagi, “From insights to value - building a modern

REFERENCES
1. S. Amershi et al., “Software engineering for machinelearning: a case study,” in 41st International Conference on Software Engineering: Software Engineering inPractice (ICSE-SEIP), 2019, pp. 291–300.
2. M. S. Rahman et al., “Machine learning software engineering in practice: An industrial case study,” CoRR, vol.
abs/1906.07154, 2019.
3. A. Serban et al., “Adoption and effects of software engineering best practices in machine learning,” in International Symposium on Empirical Software Engineeringand Measurement (ESEM). ACM, 2020, pp. 3:1–3:12.
4. H. Washizaki et al., “Studying software engineering
patterns for designing machine learning systems,” in10th International Workshop on Empirical Software Engineering in Practice (IWESEP).

IEEE, 2019, pp. 49–

54.
5. ——, “Practitioners’ insights on machine-learning software engineering design patterns: a preliminary study,”
in International Conference on Software Maintenanceand Evolution (ICSME).
6. 2021.

[Online].

IEEE, 2020, pp. 797–799.

Available:

https://doi.org/10.5281/

zenodo.5168886
7. H. Washizaki et al., “Software engineering patterns formachine learning applications (sep4mla),” in 9th Asian
Conference on Pattern Languages of Programs (AsianPLoP).

Hillside, Inc., 2020, pp. 1–10.

8. ——, “Software engineering patterns for machine learning applications (sep4mla) - part 2,” in 27th Conference
on Pattern Languages of Programs (PLoP).

Hillside,Inc., 2020, pp. 1–10.
9. J. Runpakprakun et al., “Software engineering patterns
for machine learning applications (sep4mla) - part 3,” in(under review), 2021, pp. 1–9.

logical data lake to drive user adoption and businessvalue,”

https://www.slideshare.net/Hadoop Summit/

from-insights-to-value-building-a-modern-logical-data-lake-to-drive-user-adoption-and-business-value,
2017.
15. M. Kläs and A. M. Vollmer, “Uncertainty in machinelearning applications: A practice-driven classification of
uncertainty,” in Computer Safety, Reliability, and Security (SAFECOMP) Workshops, 2018, pp. 431–438.
16. D. Sculley et al., “Hidden technical debt in machinelearning systems,” in Annual Conference on Neural
Information Processing Systems (NeurIPS).

NeuralInformation Processing Systems Foundation, 2015, pp.
2503–2511.
17. B. McMahan and D. Ramage, “Federated learning: Collaborative machine learning without centralized training data,” https://ai.googleblog.com/2017/04/
federated-learning-collaborative.html, 2017.
18. S. Ghanta et al., “Interpretability and reproducability
in production machine learning applications,” in 17th
International Conference on Machine Learning and Applications (ICMLA).

IEEE, 2018, pp. 658–664.

19. V. Lakshmanan et al., Machine Learning Design Patterns.

O’Reilly, 2020.

20. Y. Shibui, “Machine learning system design patterns,”
https://github.com/mercari/ml-system-design-pattern,
2020.

Hironori Washizaki is a Professor at Waseda University in Tokyo, and a Visiting Professor at National
Institute of Informatics. He also works in industry as
an Outside Director of SYSTEM INFORMATION andeXmotion. He serves as IEEE-CS Vice President for
PEAB. Contact him at washizaki@waseda.jp.

10. C. Wu et al., “Machine learning at facebook: Understanding inference at the edge,” in 25th International
Symposium on High Performance Computer Architecture (HPCA).

IEEE Computer Society, 2019, pp. 331–

344.
11. H. Yokoyama, “Machine learning system architectural
pattern for improving operational stability,” in International Conference on Software Architecture Companion(ICSA-C). IEEE Computer Society, 2019, pp. 267–274.

8

Foutse Khomh is a Full Professor at PolytechniqueMontréal and FRQ-IVADO Research Chair on Software Quality Assurance for Machine Learning Applications. He is also a member of Mila - Quebec AI
Institute. Contact him at foutse.khomh@polymtl.ca.
Yann-Gaël Guéhéneuc has been a full Professor
at Concordia University since 2017. Contact him at
yann-gael.gueheneuc@concordia.ca.

ComputerHironori Takeuchi is a Professor at Musashi University. Contact him at h.takeuchi@cc.musashi.ac.jp.

Takuo Doi is with Lifematics Inc. Contact him at
doi@lifematics.co.jp.

Naotake Natori is with Aisin Corporation. Contact
him at naotake.natori@aisin.co.jp.

Satoshi Okuda is with the Japan Advanced Institute of Science and Technology. Contact him at
okuda@jaist.ac.jp.

March 20229