TiLA: Twin-in-the-Loop Architecture for Cyber-Physical Production Systems
TTiLA: Twin-in-the-Loop Architecture forCyber-Physical Production Systems
Heejong Park, Arvind Easwaran
Nanyang Technological University, Singapore { hj.park, arvinde } @ntu.edu.sg Sidharta Andalam
Delta Electronics Inc., [email protected]
Abstract —Digital twin is a virtual replica of a real-world objectthat lives simultaneously with its physical counterpart. Since itsfirst introduction in 2003 by Grieves, digital twin has gainedmomentum in a wide range of applications such as industrialmanufacturing, automotive and artificial intelligence. However,many digital-twin-related approaches, found in industries aswell as literature, mainly focus on modelling individual physicalthings with high-fidelity methods with limited scalability. Inthis paper, we introduce a digital-twin architecture called TiLA(Twin-in-the-Loop Architecture). TiLA employs heterogeneousmodels and online data to create a digital twin, which followsa Globally Asynchronous Locally Synchronous (GALS) modelof computation. It facilitates the creation of a scalable digitaltwin with different levels of modelling abstraction as well asgiving GALS formalism for execution strategy. Furthermore,TiLA provides facilities to develop applications around the twinas well as an interface to synchronise the twin with the physicalsystem through an industrial communication protocol. A digitaltwin for a manufacturing line has been developed as a casestudy using TiLA. It demonstrates the use of digital twin modelstogether with online data for monitoring and analysing failuresin the physical system.
Index Terms —Digital twin, Cyber-physical system, GloballyAsynchronous Locally Synchronous
I. I
NTRODUCTION
The era of Industry 4.0 brings increased connectivity amongdevices, predictability through a large volume of data, andan ability to accurately capture states of the manufacturingshop-floor. Since the introduction of a digital twin concept byGrieves [1], it has been considered as one of the key enablingtechnologies that pushes boundaries of factory digitalisation.Digital twin is a realistic virtual representation of machinesor any form of living or non-living physical things thatcan accurately monitor, predict and optimise their operations.An advancement of today’s information and communicationtechnologies (ICT), low-powered sensor and actuator devicestogether with intelligent software and hardware platforms,make it possible to create a digital twin that tightly intercon-nects cyber and physical spaces.Nevertheless, many works found in today’s literature ondigital twin lack support for integration of heterogeneousmodels with online data for creating a scalable digital twin.In our view, a key to success in implementing a digital twin
This work was supported by Delta-NTU Corporate Lab for Cyber-PhysicalSystems with funding support from Delta Electronics Inc. and the NationalResearch Foundation (NRF) Singapore under the Corp Lab@UniversityScheme. is to identify the requirements of the target application andprovide appropriate models that can accurately capture thecharacteristics of the physical system. To achieve this, a digitaltwin architecture should support the utilisation of differentmodelling strategies for creating the twin, where each modelspecialises in certain application domains. Furthermore, it isessential to support a method to combine such heterogeneousmodels in a consistent manner and utilise gathered online datafrom a physical system to provide a holistic understanding ofthe physical systems state.One of the common mistakes in the digital twin imple-mentation is the attempts to provide every detail about itsphysical twin through a model, while not every informationis useful nor utilised in the application. In addition, it is notalways feasible to model every part of the physical phenomenausing detailed modelling mechanisms, especially for largescale systems. Building and deploying a digital twin in the realworld scenario requires not only its ability to faithfully capturedynamics of physical systems using high-fidelity techniques,but also to combine different levels of model abstractions ina deterministic way for efficiency and scalability.Recently digital twin has received considerable attention inthe fields of manufacturing, process plants, cloud computing,etc [2], [3]. Authors in [4] presented a digital twin architecturethat consists of a service system, containing data and algo-rithms, and a virtual layer that provides high fidelity models ofthe physical system. Nevertheless, methods for interconnectingdifferent model abstractions and modelling formalisms aremissing in their work. A digital twin is used in a software-defined control (SDC) framework in [5]. Their architecture,however, assumes the existence of an MES where the twindoes not directly interact with the physical system and anonline use-case of the twin is missing. A cloud-based digitaltwin architecture reference model is introduced in [6]. Onthe high-level, the model of cyber things are composed as aset of finite state machines. However, unlike our twin model,their model composition strategy does not support asynchronywhich is desirable for scalability. Tools such as Ptolemy II [7],and INTO-CPS [8] are more focused on the simulation ofcyber-physical systems (CPS) using different levels of formalmodels of computation (MoC). Yet, their focus have been onthe offline simulation of cyber-physical systems, whereas thedigital twin evolves with the system in real-time.To address the aforementioned issues and challenges, this a r X i v : . [ c s . OH ] M a r aper introduces a digital twin architecture TiLA ( T win- i n-the- L oop A rchitecture) that merges benefits of the traditionalmodel-based design and data-based modelling approachesfor creating and deploying digital twins for Cyber-PhysicalProduction Systems (CPPS). Here, all physical operations ofthe production system are captured and accessed via digitaltwin in the cyber space. In particular, our architecture enablesbuilding of a digital twin through the composition of differentlevels of modelling abstractions by using the formal GloballyAsynchronous Locally Synchronous (GALS) model of com-putation (MoC) [9]–[11]. The contributions of this paper are:1) A digital twin architecture that employs heterogeneousmodelling techniques to capture the digital twin’s be-haviour. Models with different abstractions execute andcommunicate with each other based on GALS MoC.2) Support for a cyber-physical infrastructure that facilitatesa single source of truth for the applications that dependon the online status of the physical system consistingof various assets and provides an accurate view of thephysical system through the digital twin.3) A digital twin case-study which demonstrates the useof heterogeneous models and online data for finding theroot-causes of failure in a manufacturing line. The resultalso showed that the use of heterogeneous models isfavourable for maintaining a performance of a digital twinthat has to match with a speed of the physical system.The rest of this paper is organised as follows: Section IIintroduces the three-layered software architecture of the TiLA.The semantics of GALS MoC for the digital twin used inthe architecture is given in Section III. Section IV presentsa digital twin case study called fault monitoring and analysisfor a factory assembly consisting of a two-link planar robot,conveyor belts, and inspection station for analysis. Finally,conclusions and potential future works are presented in Sec-tion V. II. A RCHITECTURE
This section presents the three-layer architecture of TiLA.An overview of the architecture is depicted in Fig. 1. Eachlayer has a number of facilities that help the higher-level layersto perform more concrete tasks.
A. Factory Layer
The Factory Layer controls the manufacturing process andforwards data to one level above called the Twin Layer. Thedata are either sensor values collected from the physical plant,such as temperature, battery levels, object positions, etc., orcontrol related data such as outputs of the controllers and theirinternal state information. The Factory Layer can also receivecontrol commands from the Twin Layer that override the localcontrol actions or tune the parameters of the control logic.Controllers need not know how digital twins are maintainednor how gathered data are utilised.As shown in Fig. 1, designers model control-logic usingsynchronous reactive (SR) languages such as Esterel [12] or
Digital TwinModels
Plant
Controller
Plant Plant Plant
Controller
Controller
Database
Twin Description FileInterconnectionData MappingModel ImportTwin Description FileInterconnectionData MappingModel Import Twin Generator FMUs(Continuous)Custom Models
SR Controller
Third-party toolsPlants SR Controllers
RuntimeSensor data Control state CompilerSR Program
Control override
FMU export
Model export
ExecutableServices
Factory LayerTwin Layer
Anomaly Detection Predictive Maintenance Scheduling OptimisationData Visualisation
Application Layer
Throughput analysis
Shared libs
Service commands Model, data retrieval ControlSimulationMonitoringSynchronisationControlFeedback
Controller
OPC-UA Server/Client
Figure 1. An architecture of TiLA: Twin-in-the-Loop Architecture their variants, which are well suited for capturing the concur-rent and preemptive nature of control-dominated behavioursin a deterministic way. The SR model is based on a formalmathematical foundation which makes the program amenableto efficient execution and verification.
B. Twin Layer1) Digital Twin:
A digital twin in TiLA is composed ofplant and controller models, which are interconnected throughuni-directional signals, and a collection of data models fororganising sensor as well as control data gathered from thephysical assets.
Definition 1 (Digital twin) . A digital twin DT in TiLA is atuple (cid:104)C , T , S , E q , E s , D(cid:105) , where • A finite set of clock-domains C such that ∀C i ∈ C , C i is a set of models { m , . . . , m n } and ∀C i , C j ∈ C , i (cid:54) = j, C i ∩ C j = ∅ . • A set of sequences of ticks T such that ∀T i ∈ T , T i = { ( n, r ) | n ∈ N , r ∈ R , n ≥ ∧ r ≥ } for a clock-domain C i , and n and r indicate a logical time instant andits corresponding value in the continuous time domain,respectively. • A finite set of set of signals S such that S i ∈ S is aset of signals for a clock-domain C i . Each signal s ∈ S i consists of a status and a value pair ( s st , s v ) where s st ∈{ , , ⊥} , s v ∈ R . • A finite set of connections between two models in differentclock-domains E q ⊆ C i × S i × S j × C j . • A finite set of connections E s ⊆ C i × S i × C i betweenmodels within the same clock-domain. • A collection of data models
D ⊆ (cid:80) ∗ × R k where (cid:80) ∗ isa set of finite-length words over alphabets. Intuitively, plants and controllers in our digital twin areheterogeneous models following GALS MoC [9]–[11] on atop level. For example, Fig. 2a shows a graphical overview of 𝒞 𝑚 𝑚 𝑚 𝑠 𝑠 𝑠 𝑠 𝑠 GALS System 𝑠 𝑠 𝑠 Environment bufferbuffer (a) 𝒯 𝒯 BOT EOT 𝑠 = 𝑎 𝑠 = 𝑏 𝑎¬𝑎 ∅/𝑏 𝑡 𝑡 𝑎 𝑡 𝑡 𝑡 𝑡 𝑏 (b)Figure 2. A graphical illustration of (a) a GALS system for a digital twin inTiLA and (b) corresponding tick execution trace for C and C a GALS system consisting of two clock-domains C and C . C has a single model m , whereas C has two models m and m . All models in the same clock-domain run concurrentlyin lock-step fashion and synchronise with each other at asequence of logical instants called ticks . As shown in Fig. 2b,each clock-domain has its own sequence of ticks, for example T = { t , t , t , . . . } and T = { t , t , t , . . . } fed to C and C , respectively. The arrows with the vertical bar indicate thetick instants. Execution of a tick consists of three main steps:(1) at the beginning of a tick (BOT) t ∈ T i , inputs to aclock-domain are captured from the external environment andtransformed into a logical entity called signals . Each signalconsists of a ternary status 1, 0, or ⊥ (unknown) and possiblya value. For each clock-domain tick, all signal statuses areresolved from unknowns to 0 or 1. In Fig. 2b, there is oneinstant of tick for C , depicted by a dotted blue box, wherethe clock-domain captures input signal s = a at BOT. (2) C then makes internal computations and emits s = b . (3) As aresult, b is transmitted to the external environment at the endof a tick (EOT). These steps take place at the same tick instantand are assumed to be instantaneous with respect to the speedof the environment [12].Signal is associated with a particular clock-domain’s tick.Since ticks for different clock-domains are unrelated (notsynchronised), a signal event generated by one clock-domaincannot be captured by another clock-domain in a reliable way.Therefore in TiLA, a point-to-point First-in-First-Out (FIFO)buffer is used for exchanging data between models in differentclock-domains; see connections between models via buffersin Fig. 2a. Finally, TiLA contains a set of data models forstoring and analysing online data gathered from the physicaltwin. Each digital twin model m ∈ C i has an associated datamodel D m ⊆ D that can be utilised by the applications usingthe digital twin for monitoring and analysing the status of thephysical system. It is structured in a similar fashion as therelational database model where the signal values are storedas elements in the rows of a table with additional informationattached as string literals. For example, when the twin modelneeds to be synchronised with the online data with a specifictimeline, the data model can provide such information.
2) Twin Description File (TDF) and Models:
This con-figuration file for a digital twin is one of the inputs to
OPC-UA Server/ClientObject Tree
WriteRead
Plant
Clock-domain
WriteRead ControlSensor readings
Clock-domain 𝑚 𝑚 𝑚 𝑚 𝑚 Figure 3. An interface between a digital twin and a physical plant via theOPC-UA object model. our architecture which contains the following components:1)
Model import describes a list of models used to create adigital twin. 2)
Interconnection describes input and output in-terconnections between the models. 3)
Data mapping describesrelations between the data model and the digital twin. A TDFtogether with models exported from third-party tools are usedto build a digital twin by the Twin Generator. White-boxmodels such as SR programs, Petri-Nets [13] and finite statemachines can be imported together with black-box modelsencapsulated in Functional Mock-up Unit (FMU). FMU is oneof the Functional Mock-up Interface (FMI) standards [14] thatprovides a set of APIs for external tools to interact with theFMUs. Once models are imported for creating a twin, TiLA’sruntime environment implements the master algorithm basedon the GALS MoC, which is not part of the FMI standardand needs to be implemented by a tool that uses the FMUs.To include non-FMU based models exported by third-partytools, the architecture provides a minimal set of wrappers toaccess these models. As a result, TiLA integrates both FMUand non-FMU based models to create a digital twin based onthe GALS MoC.
C. OPC-UA Interface
The Twin Layer collects measurable sensor and control datafrom the Factory Layer through a cyber-physical interface.Currently, this interface is implemented using the OPC-UAarchitecture [15], which includes a machine-to-machine com-munication protocol for industrial automation. In the TwinLayer, the OPC-UA server provides a list of objects that canbe accessed by the clients (physical plant and controllers).A notion of object is similar to objects in object-orientedprogramming. OPC-UA clients operate on a set of variablesand methods created by the server which are based on theinformation provided in the TDF by a designer. A typicalOPC-UA object tree created from the TDF is shown in Fig. 3,which bridges between digital twin models and their physicalcounterpart. Physical plants and SR controllers can write orread I/O signals of a model via the OPC-UA objects underthe input and the output folders. These objects are keptupdated with the latest signal values of the models at the endof respective clock-domain ticks. When applications requestan override operation and writes a value to input signal ofa model, such value is written to the associated variable in able IAPI
S FOR APPLICATIONS TO INTERACT WITH THE DIGITAL TWIN
Method Resource Data Returns Description
GET /twins - TDF Returns description of the dig-ital twin in TDFPOST /simulate
TDF JSON Requests digital twin simula-tionGET /map - AML Returns engineering data of adigital twin in AutomationMLGET /map/collada/fn - .dae Returns geometric data inCOLLADA formatPOST /create/observer
LTL JSON Creates an observer for mon-itoring eventsGET /data/query
SQL JSON Retrieves data from databasePOST/GET /model/name/port
JSON JSON Writes or reads signals of thedigital twin model
GET:/twins file:TDF createTopic()POST:/create/observerContent: spec { "topic": "event-1","uri": "..", ... } subscribe("event-1") execModels()callback()publishEvent() app service Figure 4. A use case of the monitoring service for digital twin applications the OPC-UA tree and also forwarded to the physical plant asa control signal via an OPC-UA client. Sensor data that isnot directly associated to any model inputs can be stored intodatabase via an OPC-UA method storeData() .
1) Services:
Services in the Twin Layer are used by appli-cations for retrieving and delivering information from/to thedigital twin as well as for enhancing the twin’s functionalitywith additional features. They allow applications to utilisedifferent modes of operations of the digital twin as mentionedin Section II-B. For example, an application can request aTDF for visualising the current system layout via the modeland data retrieval service, which also provides a way toaccess the digital twin database in a secure and reliable way.The simulation service is used for requesting a simulationwith a specific twin configuration. The control service isused by authenticated applications to override control ofphysical plants for remote maintenance and reconfiguration.The monitoring service can be configured to capture variousevents, such as sensor data exceeding a threshold value anddiscovering certain patterns from machine operations, based ondata gathered both from the twin as well as the physical plant.These events are transformed into domain-specific knowledgein the Application Layer. Lastly, the synchronisation serviceallows the digital twin to synchronise with the physical plantby incorporating online data during the real-time execution ofthe twin models.
D. Application Layer
Applications in this layer interact with the digital twin fordifferent use-case scenarios such as throughput monitoring,predictive maintenance, scheduling optimisation, etc. It isassumed that every application-specific logic is implementedin this layer and the digital twin only provides “facts” aboutits physical counterpart rather than trying to interpret whatthey mean to different use-cases. For instance, the Twin Layerdoes not need to know if a particular twin model is describingmechanical or electrical components nor if certain eventsdetected from a physical plant are anomalous or expected, orcompletion of a manufacturing process. Interpretation of suchinformation is done in the Application Layer that makes thedigital twin generic and usable in various application domainsrather than tailoring each digital twin for specific use-cases.A use-case of the digital twin for a monitoring applicationis illustrated in a sequential diagram as shown in Fig. 4.In this scenario, the application first requests an informationon the currently available digital twin models via an HTTPGET request /twin to the monitoring service, which returnsa TDF as a response. After examining the returned file, anHTTP POST /create/observer is sent with a monitoringspecification encoded in Linear Temporal Logic (LTL) [16].The monitoring service then generates an observer accordingto the received LTL formula and creates a topic that can besubscribed by the application. When the observer detects themonitoring event, the service publish a message to the topicthat can be used by the application in a registered callbackfunction.A list of currently available APIs to access digital twinis shown in Table I. In addition to the APIs used in theprevious example, /map returns an engineering data encodedin AutomationML [17], such as geometry (e.g. 3D infor-mation) and topology of the physical system. Using thisdata, the application can retrieve more detailed informationof the physical system that might not be found in the TDFfile. In addition, applications can request offline simulationof the digital twin model via /simulate where differentmodel configurations are passed as a TDF file. The result ofsimulation is populated in a JSON format and returned to theapplication upon the completion. Lastly, latest values of inputand output signals of individual model can be accessed viaPOST/GET calls to /model/name/port .III. GALS S
EMANTICS FOR THE D IGITAL T WIN
GALS is a superset of the SR model where multiplesynchronous islands are grouped into clock-domains, and eachclock-domain is triggered with its own sequence of ticks. Inthe following, a notation (cid:104) x, S i (cid:105) is used to describe the statesof x and corresponding clock-domain signals S i , respectively,where x is C i for a clock-domain and m for a single model.A clock-domain is a single model or collection of modelscomposed with the synchronous parallel operator || . We adopta common notation used in [18] to describe a state transitionof x where (cid:104) x, S i (cid:105) → (cid:104) x (cid:48) , S (cid:48) i (cid:105) and (cid:104) x, S i (cid:105) → x (cid:48) denote a micro-step and a macro-step state transition of x , respectively. clock-domain makes a micro-step state transition withoutprogressing its time, therefore this is considered as an inter-mediate state transition. A macro-step transition occurs whenthe clock-domain progresses time, i.e. t i +1 > t i ⇐⇒ t ni +1 >t ni ∧ t ri +1 > t ri where t n and t r are the logical and the physicaltime components of t . Synchronous composition and executionof models within the same clock-domain C i are then definedas: (cid:104) m , S i (cid:105) → m (cid:48) , (cid:104) m , S i (cid:105) → m (cid:48) (cid:104) m || m , S i (cid:105) → m (cid:48) || m (cid:48) , t m (cid:48) = t m (cid:48) (1)where || indicates the synchronous parallel operator that en-sures model synchronisation at every discrete instant of t ∈ T i within the same clock-domain.As a superset of the SR MoC, local synchronous threadsin GALS react to external events in zero time with respectto their clock-domain’s tick. This implies input and outputrelationships between models can create cyclic dependenciesthat need to be resolved before committing the model’s stateto the next tick [7], [12]. Therefore, execution of model(s)in a clock-domain C i at any arbitrary instance of a tick t ∈T i involves resolving statuses of signals S i within C i fromunknowns ⊥ : ζ ( S i ) > (cid:104)C i , S i (cid:105) → (cid:104)C (cid:48) i , S (cid:48) i (cid:105) , ζ ( S i ) > ζ ( S (cid:48) i ) , t C i = t C (cid:48) i (2) ζ ( S i ) = 0 (cid:104)C i , S i (cid:105) → C (cid:48) i , t C i < t C (cid:48) i (3) ζ : 2 S → N is a function that returns the number of unresolvedsignals whose status is ⊥ . Intuitively speaking, Eq. (2) statesthat when a clock-domain makes a transition and could notresolve all signal statuses due to a cyclic relationship betweenthem, i.e. ζ ( S i ) > ζ ( S (cid:48) i ) , the time for the clock-domain doesnot advance ( t C i = t C (cid:48) i ). On the other hand, when the statusesof all signals are resolved, i.e. ζ ( S i ) = 0 and the clock-domainmakes a macro-step transition, time progresses ( t C i < t C (cid:48) i ) andthe number of unresolved signals in t C (cid:48) i again becomes greateror equals to zero.Micro-step transitions shown in Eq. (2) occur within thesame tick and they are totally ordered as in super-densetime [7], which further assigns individual micro-step tran-sitions with an index n µ ∈ N . This is needed to findconstructiveness of model compositions (called fixed-point).We do not discuss on this matter in this paper and interestedreaders are referred to [7] for more details.Synchronisation points of different clock-domains are un-related to each other where each clock-domain has its ownnotion of tick, This means clock-domains are asynchronouswith each other in the sense that their logical ticks n are not (1) (2)(3) (4)Inspection StationAssembly Station CB1 CB2
Parts Workpiece
Figure 5. A graphical overview of the robot assembly and digital imageinspection system required to be aligned in the physical timeline r : (cid:104)C , S (cid:105) → C (cid:48) (cid:104)C >< C , S (cid:105) → C (cid:48) >< C , t C < t C (cid:48) (4) (cid:104)C , S (cid:105) → C (cid:48) (cid:104)C >< C , S (cid:105) → C >< C (cid:48) , t C < t C (cid:48) (5) (cid:104)C , S (cid:105) → C (cid:48) , (cid:104)C , S (cid:105) → C (cid:48) (cid:104)C >< C , S ∪ S (cid:105) → C (cid:48) >< C (cid:48) , t C < t C (cid:48) ∧ t C < t C (cid:48) (6)where >< indicates the asynchronous composition operator.Intuitively, the models at the top level of the GALS systemcan make state transitions in any arbitrary order given that thesystem is clock-domain starvation-free.IV. C ASE S TUDY : F
AULT M ONITORING AND A NALYSIS
In this section, a fault monitoring and analysis (FMA) ap-plication is presented as a case study for demonstrating digitaltwin creation and its use. The system consists of a two-axisplanar robot for assembling parts of electronic products and astation for inspecting potential defects through digital imageprocessing. A graphical illustration of the system consisting ofan assembly station and a defect inspection station is shown inFig. 5. The work process of this system starts with an arrival ofa workpiece pallet carrying a partially finished product at (1),which triggers the two-axis robot to pick and place the itemon the assembly area at (2). The robot then starts assemblingthe product using the parts from (3). After the job is done, therobot transfers the product on the following conveyor belt sothat the item can be examined by the inspection station at (4).The inspection takes a finite amount of time to complete. Uponcompletion of the inspection process, the product continuesto travel along the conveyor belt to the next workstation forfurther processing. The three-layer digital twin architecture ofthis system is shown in Fig. 6. The Factory Layer contains twopairs of physical plants and controllers. The first pair consistsof a two-axis robot integrated with a proportional-derivative(PD) controller, and an SR controller that controls a referencepoint fed to the PD controller. The other pair consists of acamera module and an SR controller that triggers capturing animage upon the arrival of a product at the inspection station.
A. Digital Twin Models
Twin Layer shown in Fig. 6 utilises heterogeneous modelsof four different types – (1) the mathematical model of thetwo-link planar robot, the PD controller, and the dynamics wo-Link Planar
Robot
PD ControllerSR
Controller
Inspection Station
CD1
Physical Plant(Robot, PD Controller) Physical Plant(Camera Station)Cyber-Physical InterfaceMonitoring ServiceFault Monitoring and
Analysis Application
Spec EventObserver Generator
Twin Layer
Factory Layer
Application Layer
SRController SRControllerCB1 CB2 SRController
CD2
ObserversObservers ready theta grip gripped reached dropped ready processing unstop capture fullbusyv donepower residualtorque
Figure 6. An architecture of the manufacturing system for fault monitoringand analysis of the conveyor belts captured using Modelica language [19]exported as FMUs, (2) states of the camera station captured ina Petri-Net, (3) reactive control-logic in Esterel, and (4) finiteautomata as state observers.
1) Two-Link Planar Robot:
The dynamics of the two-link planar robot is derived using Lagrange L , which is thedifference between the kinetic and potential energy [20]. L ( q, ˙ q ) = T ( q, ˙ q ) − V ( q ) (7)where q is a vector of generalised coordinates of the systemwhich in this case are joint angles of the rigid bodies. Thenthe Lagrange equation describing the dynamics of the robotis: ddt ∂L∂ ˙ q − ∂L∂q = F (8)where F is an external force (i.e. torque τ ) acting on thejoints. Assuming the movement of the robot is restricted to an xy plane, the motion of the robot can be derived as follows. B ( θ ) (cid:20) ¨ θ ¨ θ (cid:21) + C ( ˙ θ, θ ) = F (9)where the first term represents the inertial forces, and thesecond term represents the Coriolis and centrifugal forces. θ and θ are the joint angles for the first and the second link,respectively. Matrices B and C are defined as B = (cid:34) I + I + m r + m ( l + r )+2 m l r cosθ I + m r + m l r cosθ I + m r + m l r cosθ I + m r (cid:35) C = (cid:20) − m l r sinθ ˙ θ − m l r sinθ ( ˙ θ + ˙ θ ) m l r sinθ ˙ θ (cid:21) (cid:20) ˙ θ ˙ θ (cid:21) where m i , l i , and r i are mass, length, and distance to thecentre of mass for the i ’th link, respectively. I i is the momentof inertia perpendicular to the xy plane and relative to the i ’th frame at the centre of mass of the link. The structure of PDcontrol is (cid:20) u u (cid:21) = (cid:20) K p ( θ f − θ ) − K D ˙ θ K p ( θ f − θ ) − K D ˙ θ (cid:21) (10)where θ f and θ f are desired joint angles for each link. Thencombining Eq. (10) and (9) after rearrangement we get (cid:20) ¨ θ ¨ θ (cid:21) = B ( q ) − [ − C ( ˙ q, q )] + (cid:20) K p ( θ f − θ ) − K D ˙ θ K p ( θ f − θ ) − K D ˙ θ (cid:21) (11)A Modelica model has been developed for this model whosereference angle [ θ f , θ f ] T is controlled by an SR programdeveloped in Esterel.
2) The Camera Station:
The camera station is implementedusing a Petri-Net as shown in Fig. 7, which consists oftransitions (red coloured boxes), places (blue coloured circles),and arcs (arrows). In a Petri-net, the transitions fire when allof their input places, which have an outgoing arc into thetransitions, contain at least one token (shown as a black dot).When transitions fire, they consume tokens from their inputplaces and produce tokens in output places. Arcs that no parentare mapped as input signals ( s st , s v ) (Definition 1) as shown inFig. 6, which are connected to the neighbouring models withinthe same clock-domain. State of the Petri-Net is capturedbased on the number of tokens in each place. The algorithmof the inspection process is not directly captured in this modeland only the event done is to be received from the physicalplant upon its completion. Therefore, the model of this digitaltwin is coarser than the model of the two-link planar robot.Such a choice can be made when the application does notrequire a detailed view of the inspection process through thetwin, which is desirable for achieving scalability.The camera station Petri-Net has an initial marking witha single token in the place next . When a status of a signal incoming changes from 0 to 1 in any of the ticks, i.e. s st = 1 in t i and s st = 0 in t i − , the transition fires andthe number of tokens in the queue increases by one. ready indicates a detection of the workpiece at the inspectionstation via an infra-red sensor on the conveyor belt ( CB2 in Fig. 6), which fires the connected transition and createsone token each in the places inprocess and precapture simultaneously. Start of the inspection process is initiated bythe SR controller via signal capture and its completion by thephysical plant via done . This process repeats until no tokens(workpieces) remain in the queue . Outputs of this model f ull and processing are set to 1 when the number of workpiecesin the queue is > and the inspection is in-process, i.e.,there is a token in inprocess . Firing transitions are done ateach clock-domain tick following the SR MoC. The modelis developed and compiled into executable code using theIOPT-Tools [21], which is freely available to use online at http://gres.uninova.pt/IOPT-Tools/login.php .
3) Conveyor Belt:
Movement of the workpiece pallets onthe conveyor belts is modelled using velocity that varies ncoming queue full = queue.token > ready inprocess processing = inprocess.token > precapture capturewaitnext done Inputs incomingreadycapturedone
Outputs fullprocessing
Figure 7. State transitions of the inspection station captured in a Petri-Net depending on the instantaneous power of the motor describedas follows [22]: p ( t ) = √ (cid:110) U m I m [ cos (2 ω t − ϕ ) + cosϕ ]+ ∞ (cid:88) m =1 { U m I ec [ cos ((2 ω − mω r ) t − ϕ ec )+ cos ( mω r t + (cid:36) ec )] + U m I ec [ cos ((2 ω + mω r ) t − ϕ ec ) + cos ( mω r t − ϕ ec )] } (cid:111) (12)where U m and I m are the maximum three phase line-to-line voltage and supply current, respectively, ω is the supplyangular frequency, ϕ is the phase angle, m is some integervalue, and I ec , I ec and ϕ ec , ϕ ec are describing the inducedcurrent and corresponding phase angle due to the motor fault,which will be described in Section IV-B.
4) Synchronous Reactive (SR) Controllers:
The reactivecontrollers shown as dark rectangles in Fig. 6 that controlthe plant models (light-grey rectangles) are developed usingEsterel language. Esterel follows the SR MoC and a completelist of kernel statements and formal semantics can be foundin [12]. We omit the detailed implementation of this controllogic due to lack of space.
B. Use-Case Scenario
The twin models grouped into the same clock-domain, areinterconnected and executed based on the SR MoC whereinputs and outputs of the models are synchronised and resolvedat tick boundaries, i.e. BOT and EOT. In this scenario, we usethe delayed signal communication model, where all the signalevents generated from the models are delayed by one tick, toavoid the causality problem [7] in the SR MoC. From a digitalsystem designer’s perspective, this is equivalent to havinga register on a component’s input port such that the inputis delayed by a single clock tick. Communication betweenmodels in two different clock-domains is done via point-to-point FIFO buffers whose sizes are predefined to prevent bufferoverflows.Online data of the physical plant are generated via a setof simulations in Modelica [19]. A digital twin is executed inparallel with the physical plant, which is emulated by feedingthe online data to the twin models. The role of the FMAapplication is to find the root cause of abnormal activities in the physical system via the digital twin by utilising boththe online data and the models of the twin. In this section,detection of two different types of faults is illustrated basedon the workpiece inspection time.1)
A fault in the conveyor belt’s actuator . In this scenario,a fault is indicated by intermittent spikes in the instan-taneous power spectrum of the induction motor due tothe induced motor stator current from the unbalancedrotor [22].2)
A fault in the actuator of the two-link planar robot .A control algorithm for the workpiece placement onthe conveyor belt
CB2 is disturbed by actuator fault inthe robot manipulator. This results in the misalignmentof workpieces that causes increase in delays in theinspection process. We assume ramp actuator fault in thisscenario where the manipulator’s joints gradually driftfrom the actual torque reference set by the controller [23].The start and the end time of the inspection process aremonitored by the FMA application. The monitoring properties(specifications) requested by the application during runtime,are transformed into a set of observers (see the monitoringservice in Fig. 6). In this work, we use the fragment of LinearTemporal Logic (LTL) called co-safe LTL [24], which can betranslated into finite automata for monitoring certain eventsgenerated from the digital twin model.
1) Using the Model and Data Online:
Online usage ofmodel and data in this case-study are twofold. First, the digitaltwin models are synchronised with the physical system byincorporating sensor data in the executions of the models. Forexample, the completion of the inspection process, indicatedby a generation of an event done from the physical machine,triggers the transition in the Petri-Net model of the inspectionstation to fire. On the other hand, feedback from the two-link planar robot is used in a closed-loop setting for trackingthe manipulator’s trajectory. Second, the model is executedin parallel with the physical system, and the online data andthe model simulation data are combined to generate a residualvalue for detecting discrepancies.The fault classification process from the inspection delayis described as follows. The FMA application first detectsan abnormal increase in the inspection process via observerswhich is measured by the time between the occurrences ofbinary signals capture and inprocess , which are shown inFig. 7. In this example, the twin with the online data isexecuted to collect a total of 235 instances of inspectiontimes. Fig. 8a shows inspection times under a normal operatingcondition where all instances fall in between [990 , withan average of 1,200 milliseconds. In the case of the actuatorfaults from the conveyor belt CB2 or the two-link planarrobot, we assume intermittent increases in the inspection timeindicate a need for further inspection of the physical system isrequired via the digital twin models. In such a case, possiblesources of the fault are first located via causal correlationsbetween the failure node (inspection station) and the causalnode (the conveyor belt or the two-link planar robot) basedon their input and output signals and queue interconnections.
50 100 150 200 2501 , , , Inspection instances T i m e ( m s ) (a) Frequency (Hz) A m p lit ud e o f P ( W a tt s ) (b) . . − Time (s) T o r qu e ( N m ) Torque for link 1 (measured)Torque for link 2 (measured)Torque for link 1 (twin)Torque for link 2 (twin) (c)Figure 8. Results of the case study: (a) process times for inspection station under normal condition, (b) instantaneous power P spectrum for the conveyorbelt’s motor when it is in normal condition (blue line) and with eccentricity (red line) due to unbalanced rotor and (c) difference in torque generation due toramp actuator fault for the two-link planar robot. idle convθ = f c ( t ) θ = f c ( t ) asmθ = f a ( t ) θ = f a ( t ) move ( θ f , θ f ) move ( θ f , θ f ) reached ( θ f , θ f , θ , θ ) reached ( θ f , θ f , θ , θ ) Figure 9. A finite state machine model for the two-link planar robot usinglinear interpolation
To confirm the fault, the causal nodes are examined by theFMA application via a residual value generated from theonline digital twin simulation and the sensory data gatheredfrom the physical plant. In the case of conveyor belt motorfault, the fault characteristic components that appear in theinstantaneous power spectrum at frequencies 30, 60, and 90Hz are compared with the normal component frequency of120 Hz as shown in Fig. 8b. This is obtained by computingthe fast Fourier transform of the instantaneous power (Eq. 12).On the other hand, a gradual drift of the robot manipulator’sjoint from the reference torque generated from its digital twinmodel is examined in the case of the ramp actuator fault asshown in Fig. 8c.The anomaly detection algorithm for comparing the onlinedata with the data generated from the digital twin model canbe as simple as checking a threshold crossing using the modelas reference points or other approaches such as χ test, k-nearest neighbour and Bayesian methods. Once the residualvalue is analysed by the FMA application, it performs recoveryor preventive control actions accordingly through the controlservices in the Twin Layer as shown in Fig. 1. C. Model Fidelity
An effect of low and high fidelity models is investigated byutilising heterogeneous models for the FMA case study. In thisexperiment, the FMA application shown in Fig. 6 is duplicatedfor five times and an execution time of the digital twin modelsis measured with varying number of low and high fidelitymodels. More specifically, two-link planar robot models arereplaced with a state machine-based low fidelity model asshown in Fig. 9. This model captures the movements of the .
67 690 .
26 581 . . .
83 392 . Configuration A v e r a g e ti c k ti m e ( u s ) Figure 10. Average execution times for 5 FMA applications with high andlow (h-l) model fidelity configurations robot’s manipulator between between the assembly station andthe second conveyor belt as depicted as (2) and
CB2 in Fig. 6.Two states labelled as asm and conv indicate the movementof the manipulator’s end effector from the conveyor belt to theassembly station and vice-versa. In this model, joint angles forthe manipulator’s links are pre-computed and stored in tables.Functions f x in asm and conv computes linear interpolationbetween the pre-computed values based on the current time t . In this experiment, the twin models are all grouped intoa single clock-domain whose average tick time is measured.The results are shown in Fig. 10 where the notation h-l isused to indicate the ratio of the high and low fidelity models.The graph shows improvements in the average tick time ofthe digital twin model up to 1.98 times as the robot modelsare reduced to the finite state machine model. The resultindicates the heterogeneous models with varying fidelities aredesired features for building a digital twin that requires real-time simulation capability unlike traditional offline simulationtools. V. C ONCLUSIONS AND F UTURE W ORK
We presented a digital twin architecture TiLA for build-ing a digital twin based on Globally Asynchronous LocallySynchronous (GALS) model of computation (MoC). Digitaltwin in TiLA can be created from heterogeneous models withminimal support for a predefined interface that enables modelcomposition and execution in GALS. In addition, TiLA sup-orts a co-simulation capability through FMU and implementsthe GALS-based master scheduling algorithm.The current FMI standard lacks support for some of themixed discrete event-based phenomena, which are presentin the synchronous reactive subset of GALS MoC. For fu-ture work, the inclusion of the upcoming FMI 3.0 standardthat enhances hybrid co-simulation capability in the currentGALS semantics would be advantageous. Support for moreexpressive temporal logics such as Signal Temporal Logic [25]and its variants could also be used for both the monitoringspecification and model synthesis.R
EFERENCES[1] M. Grieves and J. Vickers, “Digital Twin: Mitigating Unpredictable, Un-desirable Emergent Behavior in Complex Systems,” in
TransdisciplinaryPerspectives on Complex Systems . Springer, 2017, pp. 85–113.[2] E. Negri, L. Fumagalli, and M. Macchi, “A Review of the Roles of Dig-ital Twin in CPS-based Production Systems,”
Procedia Manufacturing ,vol. 11, pp. 939–948, 2017.[3] W. Kritzinger, M. Karner, G. Traar, J. Henjes, and W. Sihn, “Digital Twinin Manufacturing: A Categorical Literature Review and Classification,”
IFAC-PapersOnLine , vol. 51, no. 11, pp. 1016–1022, 2018.[4] F. Tao and M. Zhang, “Digital Twin Shop-Floor: A New Shop-FloorParadigm Towards Smart Manufacturing,”
IEEE Access , vol. 5, pp.20 418–20 427, 2017.[5] F. Lopez, Y. Shao, Z. M. Mao, J. Moyne, K. Barton, and D. Tilbury, “ASoftware-Defined Framework for the Integrated Management of SmartManufacturing Systems,”
Manufacturing Letters , vol. 15, pp. 18–21,2018.[6] K. M. Alam and A. El Saddik, “C2PS: A Digital Twin ArchitectureReference Model for the Cloud-Based Cyber-Physical Systems,”
IEEEAccess , vol. 5, pp. 2050–2062, 2017.[7] C. Ptolemaeus,
System design, modeling, and simulation: using PtolemyII . Ptolemy. org Berkeley, 2014, vol. 1.[8] P. G. Larsen, J. Fitzgerald, J. Woodcock, P. Fritzson, J. Brauer, C. Kleijn,T. Lecomte, M. Pfeil, O. Green, S. Basagiannis et al. , “IntegratedTool Chain for Model-Based Design of Cyber-physical Systems: TheINTO-CPS Project,” in . IEEE, 2016, pp.1–6.[9] A. Malik, Z. Salcic, P. S. Roop, and A. Girault, “SystemJ: A GALSLanguage for System Level Design,”
Computer Languages, Systems &Structures , vol. 36, no. 4, pp. 317–344, 2010.[10] F. Jebali, F. Lang, and R. Mateescu, “GRL: A Specification Language forGlobally Asynchronous Locally Synchronous Systems,” in
InternationalConference on Formal Engineering Methods . Springer, 2014, pp. 219–234.[11] G. Berry and E. Sentovich, “Multiclock Esterel,” in
Advanced ResearchWorking Conference on Correct Hardware Design and VerificationMethods . Springer, 2001, pp. 110–125.[12] G. Berry and G. Gonthier, “The ESTEREL Synchronous ProgrammingLanguage: Design, Semantics, Implementation,”
Science of computerprogramming , vol. 19, no. 2, pp. 87–152, 1992.[13] J. L. Peterson,
Petri Net Theory and the Modeling of Systems . UpperSaddle River, NJ, USA: Prentice Hall PTR, 1981.[14] T. Blochwitz, M. Otter, M. Arnold, C. Bausch, H. Elmqvist, A. Jung-hanns, J. Mauß, M. Monteiro, T. Neidhold, D. Neumerkel et al. ,“The Functional Mockup Interface for Tool Independent Exchange ofSimulation Models,” in
Proceedings of the 8th International ModelicaConference; March 20th-22nd; Technical Univeristy; Dresden; Ger-many , no. 063. Link¨oping University Electronic Press, 2011, pp. 105–114.[15] “OPC Unified Architecture,” https://opcfoundation.org/about/opc-technologies/opc-ua/.[16] A. Pnueli, “The Temporal Semantics of Concurrent Programs,”
Theo-retical computer science , vol. 13, no. 1, pp. 45–60, 1981.[17] R. Drath, A. Luder, J. Peschke, and L. Hundt, “AutomationML – TheGlue for Seamless Automation Engineering,” in . IEEE,2008, pp. 616–623. [18] G. D. Plotkin, “A Structural Approach to Operational Semantics,”
Journal of Logic and Algebraic Programming , vol. 60-61, pp. 17–139,07 2004.[19] P. Fritzson,
Principles of Object-Oriented Modeling and Simulation withModelica 2.1 . John Wiley & Sons, 2010.[20] R. M. Murray, S. S. Sastry, and L. Zexiang,
A Mathematical Introductionto Robotic Manipulation , 1st ed. Boca Raton, FL, USA: CRC Press,Inc., 1994.[21] L. Gomes, F. Moutinho, and F. Pereira, “IOPT-tools – A Web Based ToolFramework for Embedded Systems Controller Development using PetriNets,” in . IEEE, 2013, pp. 1–1.[22] Z. Liu, X. Yin, Z. Zhang, D. Chen, and W. Chen, “Online Rotor MixedFault Diagnosis Way Based on Spectrum Analysis of InstantaneousPower in Squirrel Cage Induction Motors,”
IEEE Transactions on EnergyConversion , vol. 19, no. 3, pp. 485–490, 2004.[23] M. L. McIntyre, W. E. Dixon, D. M. Dawson, and I. D. Walker, “FaultIdentification for Robot Manipulators,”
IEEE Transactions on Robotics ,vol. 21, no. 5, pp. 1028–1034, 2005.[24] A. Bhatia, L. E. Kavraki, and M. Y. Vardi, “Sampling-based MotionPlanning with Temporal Goals,” in . IEEE, 2010, pp. 2689–2696.[25] O. Maler and D. Nickovic, “Monitoring Temporal Properties of Contin-uous Signals,” in