Abbas Abdulhameed
email: abbas.abdulhameed@femtost.fr

Ahmed Hammad
email: ahammad@femto-st.fr

Hassan Mountassir

Bruno Tatibouet
email: btatibou@femto-st.fr

An Approach Combining Simulation and Verification for SysML using SystemC and Uppaal

Keywords: SysML, SystemC, Simulation, Model checking, Acceleo, ATL, Uppaal

Ensuring the correction of heterogeneous and complex systems is an essential stage in the process of engineering systems. In this paper we propose a methodology to verify and validate complex systems specified with SysML language using a combination of the two techniques of simulation and verification. We translate SysML specifications into Sys-temC models to validate the designed systems by simulation, then we propose to verify the derived SystemC models by using the Uppaal model checker. A case study is presented to demonstrate the effectiveness of our approach.

INTRODUCTION

Over the last decade, the complexity of systems has considerably grown since these systems integrate an increasing number of components and a variety of technologies. At the same time, system engineers always have to reach the following main objectives; building the right systems, correctly and on time, while reducing costs.

The correct design of complex systems continues to challenge engineers. Bugs in a design that are not uncovered in early design stages can be extremely expensive. Simulation is a predominantly used techniques supported by tool to validate a design in the industry. Formal verification overcomes the weakness of exhaustive simulation by applying mathematical methodologies to validate a design. The work described here focuses upon a technique that integrates the best characteristics of both simulation and formal verification methods to provide an effective design, building them correctly and on time, while reducing costs. One purpose of modeling is to enable the analyst to predict the effect of changes to the system. Models may describe requirements, the behavior and/or the structure of the designed system, it may be used to validate the characteristics of some part or of the whole of the designed system, e.g. Its functionality or its performance. Thus, the model-based systems engineering approach using SysML [START_REF] Omg | OMG Systems Modeling Language (OMG SysML TM ) Version 1[END_REF] can be used to specify graphically all aspects of complex systems consisting of components from heterogeneous domains, in particular hardware and software. SysML is a modeling language that permits to easily obtain a specification of a complex system including structural and behavioural aspects.

An important issue in modeling is model validity. Model validation techniques include simulating the model under known input conditions and comparing model output with system output. Generally, a model intended for a simulation study is a mathematical model developed with the help of simulation software. SysML lacks formality for the required validation. Translating SysML-based specification into Sys-temC [START_REF] Bombino | A model-driven co-simulation environment for heterogeneous systems[END_REF] environments allows to enable rigorous static, and dynamic system analysis. The joint use of languages SysML and SystemC is a good way sees to satisfy the requirements of the specification and simulation. SystemC is a language with C++ -like syntax that enables the description of concurrent systems in an event-based way. It is able to describe systems from the executable specification level.

Interestingly the question of how simulation and verification can be combined to validate the characteristics of some part or of the whole of the designed system, e.g. Its functionality or its performance. We think that performance requirements can be validated by simulation, but validation of system functionalities requires the use of the formal methods of check. To combine SysML and SystemC is not enough for validating these systems, Sometimes, it is necessary to validate functional requirements by using techniques of the formal methods checking, yet SysML and SystemC do not supply tools for the check. The integration of the model checker Uppaal [START_REF] Behramm | A tutorial on UPPAAL[END_REF] in this approach would allow to complete the process of validation. Uppaal is an integrated tool environment for modeling, validation and verification of realtime systems modeled as networks of timed automata.

The main objective of this paper is to describe a methodol-ogy of modelling, simulation and validation of complex systems. This one uses the techniques of MDE(Model Driven Engineering) for the transformation of models (SysML and SystemC). We use the works presented in [START_REF] Abdulhameed | An Approach based on SysML and SystemC to Simulate Complex Systems[END_REF] for the extraction of Uppaal timed automata from SystemC. The second section of this paper addresses the state of the art of the combination of language (eg SysML) and a code environment simulation same as SystemC. The third section, describing the example of controls of traffic lights, is used to illustrate our approach and serves as an experience feed-back. The process of validation as well as thus the proposed approach are presented in the section 4, two requirements(functional and performance) are taken into account to validate them. Finally, in Section 5, we conclude and we outline some ideas for future works.

RELATED WORKS

We present works related to combining SysML with Sys-temC for validating and verifying systems. In [START_REF] Black | SystemC: From the ground up[END_REF] and [START_REF] Vanderperren | Extending UML for Electronic Systems Design: A Code Generation Perspective[END_REF], the authors defined a design methodology and a development flow for the hardware, based on a UML4SystemC profile and encompassing different levels of abstraction. Both SystemC and C profiles are consistent groups of modelling constructs designed to lift the programming features include structural and behavioral of the two coding languages to the UML modeling level. In [START_REF] Jain | Exploiting UML based validation for compliance checking of TLM 2 based models[END_REF], the paper describes a SystemC profile which is a consistent set of modeling constructs designed to lift both structural and behavioral attributes, of the SystemC language to SysML level. It provides means for software and hardware engineers to improve the current industrial(SoC), design methodology joining the capabilities of SysML and SystemC to operate at system-level by include events and time attributes. In [START_REF] Riccobene | Integrating the SysML and the SystemC-UML profiles in a model-driven embedded system design flow[END_REF], the integration is based on a mapping from the SysML to the SystemC for the structural and behavioral aspects. The refined co-design flowing starts from a SysML description at a high abstraction level. Then, it proceeds through a series of refined SystemC models, to lower abstraction levels of design. The more complex last-level SystemC coding is left to automation. An implementation allows to efficiently simulate the behaviors of the system. Before synthesizing hardware description, the verification of SystemC designs is important, to reveal errors in early stages of the development flow. In [START_REF] Bombino | A model-driven co-simulation environment for heterogeneous systems[END_REF], an approach was developed to introduce SysML as UML profile for the co-modeling of SystemC and C with code generation support. It was implemented in the context of Artisan Studio [START_REF] Hause | [END_REF]. Many implementations that consider the transformation of SysML designs into SystemC code generation, such as the Altova UModel [START_REF] Scholtz | The usability of collaborative tools: application to business process modelling[END_REF], that designs application models and generate code and project documentation, then refines designs and completes the round trip by regenerating code, that makes visual software design practical for any project. The Enterprise Architect software [START_REF] Nikiforova | Development of the Tool for Transformation of the Two-Hemisphere Model to the UML Class Diagram: Technical Solutions and Lessons Learned[END_REF]. Supports advanced MDA transformations using easy to edit transform templates, with generation and reverse engineering of source code for SystemC language, this can quickly develop detailed solutions from abstract models.

Formal verification of SystemC has recently gained significant interests [START_REF] Hajisheykhi | [END_REF]. Compared to simulations, formal verification provides full coverage, and then may improve the reliability and the robustness of the design. In [START_REF] Vardi | Formal techniques for systemc verification; position paper[END_REF], [START_REF] Groβe | HW/SW co-verification of embedded systems using bounded model checking[END_REF] the formal verification of SystemC designs was including assertion-based dynamic validation, symbolic simulation, explicit-state model checking, and symbolic model checking. There are more than software tools are presented that encapsulate the scope of SystemC design to formal verification approaches, such as the KRATOS [START_REF] Cimatti | KRATOS-A Software Model Checker for SystemC[END_REF], [START_REF] Cimatti | Software model checking SystemC[END_REF] verifies safety properties, in the form of program assertions, by allowing users to explore two directions in the verification. First, by relying on the translation from SystemC designs to sequential C programs, is capable of model checking the resulting C programs using the symbolic lazy predicate abstraction technique. Second, are implements a novel algorithms, called ESST (Explicit-Scheduler/Symbolic-Threads) and S3ST that combines explicit state techniques to deal with the SystemC scheduler, with symbolic techniques to deal with the threads, which are is built on top of NUSMV and MATHSAT, and uses stateof-the-art SMT-based techniques for program abstractions and refinements. In [START_REF] Campana | An analytic evaluation of SystemC encodings in promela[END_REF], [START_REF] Marquet | Efficient encoding of systemc/tlm in promela-full version[END_REF] the authors proposed Promela encoding of SystemC to analysis, the kinds of property and search behaviors during the verification. The technique is effective and efficient in finding bugs, describe the encoding of the SystemC scheduler into an asynchronous formalism, the input language for ("SPIN"). In [START_REF] Le | Verifying SystemC using an intermediate verification language and symbolic simulation[END_REF] IVL ("Intermediate Verification Language") combine and adapt POR (Partial Order Reduction) and symbolic execution techniques to allow the verification and the simulation of SystemC designs. IVL presents some limitations. It does not implement loop detection in the proposed symbolic simulator. In our paper, a methodology that combines SysML with SystemC and Uppaal is proposed to validate requirements of complex system. A first translation from SysML to SystemC is done to validate non functional properties by simulation. Then, a second translation from SystemC models to Uppaal is achieved to provide a formal verification of functional properties.

BACKGROUND 3.1 SysML

SysML is a language of modelling specified by the OMG. It is a language of graphic modelling with semi-formal semantics, availability scopes are to improve UML-based [START_REF] Hause | Testing safety critical systems with SysML/UML[END_REF], complex systems development processes with the successful experiences from the system engineering discipline.

BDD and IBD

The Block Definition Diagram"BDD", is specified by its parts, and its flow ports. The physical components of the block is referred to Parts and the interfaces of block is referred to Flow ports [START_REF] Riccobene | Integrating the SysML and the SystemC-UML profiles in a model-driven embedded system design flow[END_REF]. Internal Block Diagram "IBD" includes properties so that its values, parts, and references to other blocks can be specified. However, created for a block (as an inner element) will only display the inner elements of a classifier (parts, ports, and connectors).

SMD

The State Machine Diagram "SMD" facilitates the specification of a state-based behaviour of any component whose behaviour can be thus expressed; some components will additionally require other mechanisms to define their nonstatebased behaviour [START_REF] Wood | A model-driven development approach to mapping UML state diagrams to synthesizable VHDL[END_REF]. The SMD defines a set of concepts that can be used for modeling discrete behaviour through finite state transition systems. The state machine represents behaviour as the state history of an object in terms of its transitions and states.

A block includes operations so that its values, parts, and references execution blocks can be specified. However, whereas an SMD created from a block will display the inner elements of a classifier, through the transition, entry, and exit, the states are specified along with the associated event and guard conditions. The state can be active or inactive, state has incoming transitions and outgoing transition; when an outgoing transition is fired, the state is exited and becomes inactive. When an incoming transition is fired, the state is entered and it becomes active. Activities that are invoked while in the state are specified asdo Activities, and can be either continuous or discrete. A composite state has nested states that can be sequential or concurrent [START_REF] Omg | OMG Systems Modeling Language (OMG SysML TM ) Version 1[END_REF].

SystemC

SystemC [START_REF]IEEE Standard for Standard SystemC Language Reference Manual. IEEE Std 1666-2011[END_REF], is an open-source system-level design language based on C++ that has its own simulation kernel. The Sys-temC is a run-time scheduler that handles both the synchronization and scheduling of concurrent processes. The designers can apply object-oriented capabilities to hardware design. SystemC allows to work at a higher level of abstraction, enabling extremely faster, more productive architectural trade-off analysis, design functional level modeling describes modeling done at levels above Transaction Level Modeling (TLM) and encompasses System Architectural Models(SAM)with System Performance Models [START_REF] Boutekkouk | Automatic SystemC code generation from UML models at early stages of systems on chip design[END_REF].

Modeling at this level is algorithmic in nature and may be timed or untimed. Models may represent software, hardware or both the typical behavior is described as generators and consumers of data. Processes may be assigned time for performance analysis purposes, this timing does not cycle accurate but rather describes the time to generate or consume data or to model buffering or data access. The behavior of the interfaces between modules is described using communication protocols. These types of models are used to explore architectures, for proof of algorithms and for performance modeling and analysis. SystemC processes execute concurrently and may suspend on "wait()" statements. Such processes require their own independent execution stack which called "SC THREADs", when the only signal triggering a process is the clock signal "clk" we obtain what we call "SC CTHREADs" (clocked thread process) certain processes do not actually require an independent execution stack and cannot suspended on "wait()" statement, such processes are termed "SC METHODs". Processes are executing in zero simulation time and returns control back to the simulation kernel.

Simulation Semantics of SystemC

A high-level executable design allows to efficiently simulate the behaviours of the complex system before synthesizing the RTL hardware description. The verification of SystemC designs is of fundamental importance, to detect errors in early stages of the development flow, and prevent expensive propagation down to the hardware.

Formal verification of SystemC is lately winning significant interests. Compared to simulations, formal verification provides full coverage, and thus may enhance the reliability and the robustness of the design.

The controller of SystemC design is scheduled when exe-cution. It controls the simulation time, the execution of processes, manages event notifications and updates primitive channels. SystemC supports the notion of delta-cycles, the delta cycle is not clock cycle and no time having advanced. Delta-cycles are used to simulate new updates and event triggered processes to be simulated from the current execution phase of current time. A brief simulation steps are as follows:

1. Initialization phase: each process is executed once, 2. Evaluation phase: execute all schedule processes in current run queue.

3. Update phase: update value and add new triggered runnable processes to waiting queue or queue of t + n.

4. If the queue (t+0) is not empty, move queue (t+0) to run queue and go to step 2.

5. If waiting queue (t+0) is empty, advance time to closest time step, and move queue (t+x) to run queue and go to step 2.

6. If queue is empty, it means no event needs to be simulated, then simulation ends.

Which is using delta notification, the event and its triggered processes are scheduled to be run immediately after current execution and update phase.

Uppaal Timed Automata

Timed Automata [START_REF] Bengtsson | Timed automata: Semantics, algorithms and tools[END_REF] is a Finite-State Machine extended with clock variables. The concept of model time-dependent behavior of clock variables, which are used as clock constraints. Systems comprising multiple concurrent processes are modeled by networks of timed automata, which are executed with interleaving semantics and synchronize on channels. Uppaal [START_REF] Behramm | A tutorial on UPPAAL[END_REF], [START_REF] Behrmann | UPPAAL 4.0. In Quantitative Evaluation of Systems[END_REF] is a toolset for the modeling, simulation, animation and verification of networks of timed automata. The Uppaal model checker enables the verification of temporal properties. The simulator can be used to visualize feed-back produced by the model checker.

Uppaal Model Checking Tool

The Uppaal modeling language extends timed automata by introducing parameterized timed automata templates, bounded integer variables, binary and broadcast channels, and urgent and committed location. Timed automata templates provide the possibility to model similar timed automata only once and to instantiate them arbitrary often with different parameters.

A Uppaal model comprises three parts: "global declarations", "parameterized timed automata" and a "system declaration".

In the global declarations section, global variables, constants, channels and clocks are declared. The timed automata templates describe timed automata that can be instantiated with different parameters to model similar process. In the system declaration, the templates are instantiated and the system to be composed is given as a list of timed automata.

To enable the implementation of formal verification techniques, the dynamic requirements are formalized into TCTL properties "Time Computation Tree Logic" [START_REF] Penczek | Towards bounded model checking for the universal fragment of TCTL[END_REF], TCTL is an extension of CTL "Computation Tree Logic" which allows considering several possible future from a state of system. The model checker Uppaal has four TCTL quantifiers [START_REF] Friesen | On Challenges in Enterprise Systems Management and Engineering for the Networked Enterprise of the Future[END_REF] 3.4 Metamodels MDE recommends the use of models at different levels of abstraction. The model is an abstract view of reality and conforms to a metamodel that precisely defines the concepts present at this level of abstraction and the relationships between the concepts, therefore the metamodel allows of representing complex mechanisms involving multiple concepts, a written report in a given metamodel will be said according to the metamodel. The metamodeling approach means that "a metamodel is used to specify the model that comprises (SysML, SystemC)".

Model transformation

Model transformation represents the heart which becomes an MDE predominant activity in the development process.

To the principle of model transformations has attracted much attention by becoming a subject of research for the academy and industry. The transformation term models remain quite broad as a consequence of studies have been done order to define categories and criteria for model transformation by allowing developers to choose an approach as needed.

Several conditions were adopted order to define the transformation process that generally describes by the conversion of a certain level of model abstraction complies to a metamodel to a target at a certain level of abstraction compliance with its metamodel whose passage is described by of the rules of transformation,

OVERALL APPROACH

This section introduces the set of activities related to the specification and the verification approach used to assess the correction of complex systems designed with SysML, simulated by SystemC, and verified using Uppaal. Figure 1 summarises the main steps of the proposed approach. First, we have to create the SysML diagrams "BDD, IBD, SMD", for specifying the system structure and behaviour. Then, the SysML diagrams are mapped into SystemC modules. Then, the derived SystemC specification is mapped into Uppaal automata. Properties to verify by uppaal are derived from SysML Requirements Diagram "RD".

THE MAPPING TECHNIQUE 5.1 Mapping SysML to SystemC

In this section, we will focus on how to implement (and what are the parameters used to affect the implementation), and learn the structure and behaviour modeling and generate a SystemC specification. The mapping methodology is used to create SystemC code from SysML diagrams will focus over the next subsections.

Design SysML Diagrams

The SysML diagrams are modeled using the TOPCASED tool. Topcased is a graphical tool that capture SysML diagrams, with our combination the SysML and SystemC profiles start from a system description given as the input conditions of

From SMD to SystemC

The aim of extending the model with state machine diagram is to introduce and translate behavioral information about the system to the target language, in this case SystemC.

There are different possible translations of the considered semantics with the behavioral concepts of SystemC [START_REF] Agosta | UML Tailoring for SystemC and ISA Modelling[END_REF]. The following translation rules were chosen 1. A SMD is mapped into SystemC process.

2. A SystemCThreads are used to allow parallel states activation semantics.

3. The activation of each state is represented by a boolean signal, more than one state can be active at the same time.

4. A SystemCThreads are sensitive each one to another by notification to represent every event trigger which can possibly fire transition from the associated state.

Description of the implementation approach

The general process of our approach consists of several stages, in the first place the modeling with SysML diagrams which will be the source models for the transformation. Our purpose in this work is the transformation of three diagrams: BDD, IBD and SMD diagrams. With model transformation "Model2Model", was chosen ATL language, such as language and the transformation method allowing passing a SysML model to a model SystemC. The application of the methodology with ATL is based primarily on 1. The definition of the source and target metamodel.

2. The definition of the style of transformation.

3. The definition of the source model that conforms to source metamodel.

The source metamode represent the SysML metamodel and the metamodel target will SystemC. Both are carried out under the metamodel formalizes of Eclipse EMF Ecore, the different stages of implementation are shown in Figure 2.

Transformation with ATL

After the definition the metamodel of SysML, SystemC and models sources of SysML diagrams, we use ATL as transformation language models. With the aim of achieving the previously defined rules ATL declarative "rule" is used. ATL rule is characterized by two mandatory elements:

1. A pattern on the source model "from" with a possible constraint.

2. One or more grounds of the target model "to" that explain how target elements are initialized from the corresponding source element.

When creating a target item from a source element, ATL retains a traceability link between the two elements. This link is used to initialize a target item in the "to" match as seen in Listing 1.

The ATL following code shows an example of the rules used in the ATL model transformation

Code Generation

Acceleo is a language code generator which allows generating structured file from an Eclipse Modeling Framework(EMF) [START_REF] Nicolescu | Design technology for heterogeneous embedded systems[END_REF] model, the output is a text that can be a programming language or other formalism. Acceleo requires defining an EMF metamodel and a model conforming to metamodel that will result into text.

Once this definition is done, then we can execute the code generator, in this example, have the metamodel and model of SystemC for code generation, we need to create an Acceleo project and configure the workflow necessary to code generation specifying the link between the generator, the metamodel and model.

After it is needed to define the Template code using the keywords of SystemC language and attributing information from the SystemC model of transformation. In the first line of Acceleo code we are importing the metamodel so that the generator knows the structure of our model. The important concept to define Acceleo is also called Template, it is the smallest unit identified in a template file, and allows to define the main reference for the workflow order to collect information from the necessary to model code generation. Figure 3,4 illustrates the SysML2SystemC code.

Mapping SytemC to Uppaal

To provide a formal verification of SystemC designs, we use existing tools to transform, by sequence of refinement steps, a systemC design into an Uppaal automata. Our objective is to analyse a SystemC design with model-checking techniques. As shown in Figure 5, the tool STATE (SystemC to Timed Automata Transformation Engine) [START_REF] Pockrandt | Optimized Transformation and Verification of SystemC Methods[END_REF] is used to translate an abstract SystemC design into a Uppaal model and the Uppaal model-checker is used to check properties

CASE STUDY

This section discusses a case study with the aim to present the effectiveness of our approach to specify, validate and verify the behavior of road intersection signals. The state sequence of the car flow in the crossroad is the base of the traffic behavior. Some additional features have been added to make this workbench complex enough to measure meaningful evaluations of development system properties. They are managed by a system that synchronizes the color changes of the different junction lights. The traffic-light colors are managed by a controller which depends on the number of cars waiting to cross the junction. The methodology and code generator presented were used, for example, to show it, BDD with six blocks. The first block is the most abstract level of the modeling Crossroads block named CrossRoad represents the system as a whole, it is composed of three sub-blocks("Controller System, NorthandSouthLights, Eas-tandWestLights")and sub-sub blocks ("Timer, Road Sensor , Camera"). Figure 6 illustrates the crossroads top level modeling.

To represent the internal structure of the Crossroads block by IBD. The diagram shows the flow ports, the port management allow continuous moving the direction of Controller System and the port of other parts (i.e. "NorthandSouth-Lights, EastandWestLights"). Figure 7 shows the IBD di- If the state has any unconditional Transition Line, then assigning default state to next state is omitted as shown in case "State0", we see that the next state conditions appear in the generated SystemC code according to the assigned priority. Consider the following situation where,"NS" and"WE" are two inputs for a state machine. "if (NS==1) and (WE==0) NextState = State1" "else if (NS==1) NextState = STate2" If both "NS and EW are 0", then NextState is dependent on the order of the appearance of the conditions in the code. Figure 8 shows the SMD diagram. The timer for the crossfires is managed by a controller system which at each start up, initializes a clock that measures the duration for each crossfire color: red (38 Sec.), yellow (5 Sec.), and green (33 Sec.), then it sends the value to NorthandSouth-Lights and EastandWestLights, based on the given entries "NorthRed, North Yellow,...WestGreen". Figure 10 show the results of validation of the Crossroades system.

Simulation

When SystemC code is successfully generated from the SysML representation of the Crossroades system (Figure 6, 7 and 8), the subsequent step is to simulate the generated Sys-temC design. In Figure 9, we show the simulation results. The simulator shows the state of each light as true and false values through the time. There we can verify that no green light on North and South lights is turned on when there is also a green light on the East and West lights.

Verification

To verify requirements of the Crossroades system, the Sys-temC design is translated into Uppaal automata. Requirements are expressed as temporal logic properties expressed in TCTL. First, we verify that the system is deadlock free. we express this property in TCTL by the formula: "AG not deadlock" . Then, we verify time properties. As example, we verify that both NorthandSouth Lights and EastandWest Lights can not stay in yellow color more than 5 second, which is expressed in TCTL as: A. AG(NorthSouth.NY imply NorthSouth.cn<5). B. AG(EastWest.SY imply EastWest.cs<5)). Then, we verify that both NorthandSouth Lights and Ea-standWest Lights can not stay in red color more than 38, which we express in TCTL as: A. EG(NorthSouth.cn>38). B. EG(EastWest.cs>38). In Figure 10, we present Uppaal environment, where Uppaal automata, properties and their verification results are shown.

CONCLUSION AND FUTURE WORK

In this paper we proposed a methodology for verifying and validating complex systems designed with SysML. We have

Figure 1 :

 1 Figure 1: Methodology of the global approach

5 .

 5 In SystemCThreads, condition statements are used to represent the guards used in SMD. By applying this rules, the basic mappings of SMD elements into SystemC Processes are as follows: A. State → State of the process(case statement) B. Peudostate → State of the process(condition statement) C. Transition → Action of the process(event statement ) D. Do activity → Action of the process(action statement)

Figure 2 :

 2 Figure 2: Approach Transformations

Listing 1 :

 1 rule model to model r u l e Model2SCModel { from s y s m l : MMUML! Model ( s y s m l . o c l I s T y p e O f (MMUML! Model ) ) t o scModel : MMSystemC ! SCModel ( name <-s y s m l . name ) } r u l e Package BDD2SystemC Main { from BDD :MMUML! Package ( BDD. o c l I s T y p e O f (MMUML! Package ) ) t o Top : MMSystemC ! S C o b j e c t ( name <-BDD. name , ownerScModel <-BDD. getModel ( ) ) }

Figure 3 :

 3 Figure 3: Code generation BDD, IBD To SystemC

Figure 4 :

 4 Figure 4: Code generation SMD To SystemC

Figure 5 :

 5 Figure 5: Methodology Model Transformation

Figure 6 :

 6 Figure 6: Top level modeling

Figure 7 :

 7 Figure 7: IBD of Crossroads

Figure 8 :

 8 Figure 8: SMD of Controller System block

Figure 9 :

 9 Figure 9: Graph from code simulation

Figure 10 :

 10 Figure 10: Uppaal environment


Vassilis Koutkias
email: vasileios.koutkias@inserm.fr

Marie-Christine Jaulent
email: marie-christine.jaulent@inserm.fr

A Multiagent System for Integrated Detection of Pharmacovigilance Signals

Keywords: Pharmacovigilance, Computational Signal Detection Methods, Heterogeneous Data Sources, Multiagent System, Aggregation and Reasoning Scheme

Pharmacovigilance is the scientific discipline that copes with the continuous assessment of the safety profile of marketed drugs. This assessment relies on diverse data sources, which are routinely analysed to identify the so-called "signals", i.e. potential associations between drugs and adverse effects, that are unknown or incompletely documented. Various computational methods have been proposed to support domain experts in signal detection. However, recent comparative studies illustrated that current methods exhibit high false-positive rates, significantly variable performance across different datasets used for analysis and events of interest, but also complementarity in their outcomes. In this regard, in order to reinforce accurate and timely signal detection, we elaborated through an agent-based approach towards systematic, joint exploitation of multiple heterogeneous signal detection methods, data sources and other drug-related resources under a common, integrated framework. The approach relies on a multiagent system operating based on a collaborative agent interaction protocol, aiming to implement a comprehensive workflow that comprises of method selection and execution, as well as outcomes' aggregation, filtering, ranking and annotation. This paper presents the design of the proposed multiagent system, discusses implementation issues and demonstrates the applicability of the proposed solution in an example

Introduction

The importance of drug safety is widely recognised [START_REF] Who | The Importance of Pharmacovigilance: Safety Monitoring of Medicinal Products[END_REF]. Pharmacovigilance encompasses all data gathering and processing activities related with the detection, assessment, understanding and prevention of adverse effects throughout the entire lifecycle of drugs [START_REF] Grootheest | [END_REF].

One of the most important aspects in the monitoring of marketed drugs is the identification and analysis of new, medically important findings, so-called signals that might influence the use of a medicine. Signals have been defined1 by the Council for International Organisations of Medical Sciences (CIOMS) VIII Working Group as "information that arises from one or multiple sources (including observations and experiments), which suggests a new potentially causal association, or a new aspect of a known association, between an intervention and an event or set of related events, either adverse or beneficial, that is judged to be of sufficient likelihood to justify verificatory action" [START_REF]Practical Aspects of Signal Detection in Pharmacovigilance: Report of CIOMS Working Group VIII[END_REF]. In the scope of this work, we focus on adverse events.

In the pre-market stage, clinical trials of newly developed drugs constitute the main procedure for identi-fying Adverse Drug Reactions2 (ADRs) resulting from their use. However, due to time constraints, the limited sample population size as well as potential bias, clinical trials do not enable the detection of all possible ADRs. Consequently, post-marketing surveillance is necessary to identify new or incompletely documented ADRs throughout the time a drug is actively prescribed [START_REF] Who | A Practical Handbook on the Pharmacovigilance of Antimalarial Medicines[END_REF]. Active and systematic surveillance requires constant assessment of all drugs for any outcome [START_REF] Grootheest | [END_REF].

Given the necessity to identify as early as possible signals, it has become evident that all the available data sources have to be explored [START_REF] Kelman | Evaluating medicines: let's use all the evidence[END_REF]. In the post-marketing context, these sources vary, spanning from spontaneous reports, electronic health records [START_REF] Trifirò | Data mining on electronic health record databases for signal detection in pharmacovigilance: which events to monitor?[END_REF], scientific literature [START_REF] Gurulingappa | Automatic detection of adverse events to predict drug label changes using text and data mining techniques[END_REF], and even social media [START_REF] Sarker | Utilizing social media data for pharmacovigilance: a review[END_REF]. The availability of this data deluge dictates the need to introduce highthroughput computational methods that will enable efficient knowledge extraction and management, compensating the underlying heterogeneity and complexity.

To this end, various computational signal detection methods have been proposed to explore the above types of data sources [START_REF] Harpaz | Novel data mining methodologies for adverse drug event discovery and analysis[END_REF]. However, these methods are designed for application in a single data source and typically demonstrate high false-positive rates in the provided results. In addition, the task of assessing the outcomes of analysis methods is currently performed manually and requires significant effort. Overall, accurate, timely and evidence-based signal detection remains a challenge [START_REF] Hauben | A decade of data mining and still counting[END_REF].

The current work concerns integrated signal detection, i.e. a systematic, joint exploitation of multiple heterogeneous signal detection methods, data and other drug-related resources under a common framework, addressing methods' selection and execution, as well as outcomes' aggregation, filtering, ranking and annotation. Heterogeneity refers both to the methods' underlying computational models and the data that they can analyse. This paper presents an agent-based approach for the construction of a knowledge-intensive platform to accommodate these requirements, relying on a multiagent system that operates based on a collaborative agent interaction protocol.

The paper is structured as follows: In section 2, we provide background information concerning computational signal detection and comment on the motivation of this work. In section 3, we describe the challenges that this work implies and we justify the adoption of the agent paradigm. We then present the architecture of the proposed multiagent system, including agent classes and the overall integrated signal detection strategy. In section 4, we provide details for our prototype implementation as regards the material and the development tools that have been employed. Equally important, we also illustrate the functionality of the multiagent system through an example signal detection scenario. In section 5, we discuss our contribution in comparison with related works and highlight current limitations and future work plans. Finally, section 6 concludes the paper.

Computational Signal Detection: Background and Motivation

Computational analysis methods constitute a well established support tool for signal detection [START_REF] Harpaz | Novel data mining methodologies for adverse drug event discovery and analysis[END_REF]. Computationally extracted signals can be considered as potential causal relations that have to be verified. As such, they are perceived as early indications informing drug safety experts for appraisal actions, which require the review/analysis of scientific literature, clinical trial data, biological properties of drugs, etc., before concluding at causality.

The output of computational signal detection methods is a list of drug-event pairs, which shall be ideally ranked based on significance factors (statistical or probabilistic), in order to drive the focus of appraisal actions. Since these actions are typically performed manually, they require significant effort and, given the large amount of generated indications, they result in a bottleneck in the pharmacovigilance process [START_REF] Shang | Identifying plausible adverse drug reactions using knowledge extracted from the literature[END_REF]. Thus, besides highly accurate detection methods, filtering mechanisms are necessary, in order to exclude: (a) known ADRs, but also (b) associations containing conditions corresponding to the drugs' indicated use, which can be also generated as potential signals, according to the data being explored.

As the volume of data for signal detection is constantly increasing with new sources being considered for analysis (like patient-generated content in social media platforms), the need for advanced computational signal detection frameworks becomes imperative [START_REF] Koutkias | Computational approaches for pharmacovigilance signal detection: toward integrated and semantically-enriched frameworks[END_REF]. Based on their nature and the computational analysis that they require, the main data sources for signal detection can be categorised into: a) spontaneous reporting systems, b) structured, longitudinal observational healthcare databases, and c) unstructured / free-text data sources.

In particular, spontaneous reporting systems (SRSs) constitute the dominant source of signals through which suspected cases are voluntarily reported by healthcare professionals (and in some cases by patients) to regulatory authorities and other bodies. Prominent SRSs are the Food and Drug Administration (FDA) Adverse Event Reporting System (FAERS [START_REF]FDA Adverse Event Reporting System (FAERS[END_REF]) in US, EudraVigilance maintained by the European Medicines Agency [START_REF] Eudravigilance | [END_REF], and VigiBase R maintained by the Uppsala Monitoring Centre [START_REF] Vigibase | [END_REF]. The main type of signal detection methods for analysing SRS data relies on the statistical investigation of "disproportionality" (i.e. assessing whether a specific event is reported more frequently for a drug than would be expected if randomly occurring) [START_REF] Hauben | Decision support methods for the detection of adverse events in post-marketing data[END_REF]. Another category of methods exploiting SRS data are the so-called "multivariate" [START_REF] Harpaz | Novel data mining methodologies for adverse drug event discovery and analysis[END_REF], such as logistic regression-based and unsupervised machine learning methods, which are able to analyse more complex drug safety incidents compared to disproportionality-based methods.

Structured observational healthcare data originate mostly from Electronic Health Record (EHR) and administrative claim systems. These data sources have been considered in terms of secondary use for the identification of potential causal relations between drugs and adverse conditions [START_REF] Trifirò | Data mining on electronic health record databases for signal detection in pharmacovigilance: which events to monitor?[END_REF], [START_REF] Chazard | Data mining to generate adverse drug events detection rules[END_REF]. Compared to spontaneous reports, observational data contain more information, such as diagnosis and lab examination results. The corresponding signal detection methods typically involve the application of data mining techniques in large datasets [START_REF] Reps | Comparison of algorithms that detect drug side effects using electronic healthcare database[END_REF]. A number of methods have been also proposed having their origin from statistical epidemiology, relying on case-control design [START_REF] Madigan | Empirical performance of the case-control design: lessons for developing a risk identification and analysis system[END_REF], cohort design [START_REF] Ryan | Empirical performance of a new user cohort method: lessons for developing a risk identification and analysis system[END_REF], self-controlled case series design [START_REF] Suchard | Empirical performance of the self-controlled case series design: lessons for developing a risk identification and analysis system[END_REF], selfcontrolled cohort design [START_REF] Norén | Temporal pattern discovery in longitudinal electronic patient records[END_REF], etc. Notably, the Observational Medical Outcomes Partnership (OMOP) gathered an open-source library of such methods [START_REF]The Observational Medical Outcomes Partnership[END_REF].

In the category of unstructured free-text data, typical sources include clinical narratives, scientific literature and patient self-reports. Clinical narratives remain a significant part of EHR systems, in which information concerning diagnosis and patient treatment (including drugs) is documented [START_REF] Lependu | Pharmacovigilance using clinical notes[END_REF]. Scientific literature may also provide indications for pharmacovigilance signals [START_REF] Shang | Identifying plausible adverse drug reactions using knowledge extracted from the literature[END_REF] as well as evidence to support the evaluation of findings obtained by other sources. Patient selfreports about drug concerns/problems that are shared among networked communities using social media are an emerging source of signals [START_REF] Freifeld | Digital drug safety surveillance: monitoring pharmaceutical products in Twitter[END_REF]. However, the subjective nature and the lack of quality control in the generated data constitute important limitations for reliable signal detection. Independently of the data source that is being employed, computational signal detection using unstructured text relies on information extraction and natural language processing (NLP) techniques [START_REF] Harpaz | Text mining for adverse drug events: the promise, challenges, and state of the art[END_REF].

Interestingly, recent comparative studies of computational signal detection methods have highlighted [START_REF] Harpaz | Performance of pharmacovigilance signal-detection algorithms for the FDA adverse event reporting system[END_REF]- [START_REF] Van Holle | Signal detection on spontaneous reports of adverse events following immunisation: a comparison of the performance of a disproportionalitybased algorithm and a time-to-onset-based algorithm[END_REF]: (a) high false-positive rates, (b) significantly variable performance across different datasets used for anal-ysis and events of interest, but also (c) complementarity among methods' outcomes. These findings reinforce the argument for the joint exploration of as many data sources as possible through diverse computational signal detection methods. Another argument for combined signal detection is that potential signals replicated in multiple data sources may indicate increased confidence in establishing a causal relation among drugs and adverse effects and, thus, they are more likely to be true. For example, this hypothesis has been successfully evaluated in [START_REF] Harpaz | Combing signals from spontaneous reports and electronic health records for detection of adverse drug reactions[END_REF], combining EHR and SRS data.

To this end, the motivation of this work concerns the design and development of a systematic framework enabling large-scale combinatorial signal detection as described in the following section.

3 An Agent-based Approach for Integrated Signal Detection

Challenges and Adoption of the Agent Paradigm

Our view for computational signal detection concerns an integrated framework in which joint exploitation of multiple heterogenous drug safety data sources can be performed through relevant computational signal detection methods, as well as other drug information sources. However, this broader exploitation increases the complexity of the signal detection procedure for the endusers and requires a technical framework to be set.

More specifically, from the users' perspective, the technical complexity caused for example by many parameters offered by some detection models3 , has to be addressed. Similarly, users could be interested in exploring only specific data sources, e.g. based on their origin, coverage and / or content, thus, selection shall be facilitated. In this respect, support in study setup and selection of the resources that will be used is important.

Since the focus in signal detection concerns new ADRs, noisy indications (e.g. known ADRs or associations linking the drug with its indicated use) have to be filtered by accessing reference knowledge. Given the fact that computational signal detection methods typically generate many potential indications for ADRs, the remaining findings shall be ranked to prioritise their subsequent assessment by drug safety experts. In addition, supportive information on the findings would increase their comprehension, beyond just providing statistical measures on each drug-event pair. Such informa- tion may constitute, for example, the toxicity profile of the drug of interest, recent relevant published studies, as well as information about potentially relevant clinical trials. At a lower level, technical challenges include the development of efficient mechanisms for interfacing with data sources and signal detection methods, as well as aggregating and synthesising method outcomes.

In this regard, Figure 1 depicts the overall signal detection workflow elaborated in this work, starting from study setup and concluding with outcomes annotation and enrichment with supportive information. For the implementation of this workflow, we elaborate on a software platform, in order to address two major aspects. First, the semantic harmonisation of key concepts / information models of signal detection methods available through the platform. Second, the aggregation of the methods' outcomes and the assessment of the findings' strength. For the first part we developed the Pharmacovigilance Signal Detectors Ontology (PV-SDO), which has been presented in [START_REF] Koutkias | Leveraging postmarketing drug safety research through semantic technologies: the PharmacoVigilance Signal Detectors Ontology[END_REF], while the second part is addressed via a multiagent system that is presented in the current paper. We adopted the "software agent" paradigm, as it offers a favourable way to consider complex systems with multiple distinct and independent components. Agents enable the aggregation of different functionalities in a conceptually embodied and situated whole, while at the same time may exhibit autonomous, social, reactive and/or proactive features [START_REF] Singh | Service-Oriented Computing: Semantics, Processes[END_REF]. This offers appropriate abstractions for the design and development of large systems of individual agents and of ways in which agents may interact, while taking into account organisational or macro-level issues. Especially through task decomposition and coordination, software agents can contribute in the accomplishment of complex goals and tasks. In the current work, agents provided us with a way of structuring a system around autonomous communicative elements [START_REF] Luck | A manifesto for agent technology: towards next generation computing[END_REF], through which we develop mechanisms for automating and improving signal detection in an integrated framework, supporting drug safety experts in accomplishing this task.

Since our ultimate goal is the development of an extensible platform in which new methods, raw data and other relevant data/information sources can be incorporated, the modularity and reusability offered by the agent paradigm [START_REF] Isern | Agents applied in health care: a review[END_REF] enable us to design a sustainable and scalable architecture comprising of diverse components as presented in the following subsection.

System Architecture: Resources and Agent Classes

In order to implement the workflow presented in Fig. 1, we defined a system architecture comprising of software agents, non-agent software components, data / information sources, and a knowledge component. Non-agent software components correspond to implementations of signal detection methods, while data sources provide the raw data employed for signal detection (e.g. spontaneous reports, EHR data, etc.). Information sour-ces provide reference data on known ADRs and other drugrelated information, while the knowledge component corresponds to an ontology-based Semantic Registry describing all the resources of the framework based on PV-SDO [START_REF] Koutkias | Leveraging postmarketing drug safety research through semantic technologies: the PharmacoVigilance Signal Detectors Ontology[END_REF].

We formulated a collaborative agent team, which operates according to an agent interaction protocol that we defined [START_REF] Klusch | Brokering and matchmaking for coordination of agent societies: a survey[END_REF], corresponding to the implementation of each step of the integrated signal detection workflow of Fig. 1. In this regard, agents exploit the resources available in the system, so that signal detection methods are appropriately selected and launched, using the Semantic Registry, while their results are aggregated and post-processed via filtering (to discard noisy indications) and ranking (based on their significance) mechanisms, using the reference ADR and drug information sources, respectively.

Appropriate agent classes were defined to support this functionality. Initially, the main principle for defining these classes was task decomposition and distribution [START_REF] Durfee | Distributed Problem Solving and Planning[END_REF], so that each agent is delegated a specific and simple task to accomplish, and the computational burden underlying integrated signal detection is distributed among agents. In the overall analysis and design phase, we followed the principles of MOBMAS [START_REF] Tran | MOBMAS: a methodology for ontology-based multi-agent systems development[END_REF], a comprehensive methodology that covers the main activities of developing multiagent systems (analysis, multiagent organisation design, agent internal design, agent interaction design, and agent architecture), which is relevant with the development of ontology-based multiagent systems. Based on the collaborative agent interac- tion protocol, agent activities are coordinated and result in a multiagent system that performs the proposed integrated signal detection via teamwork.

Figure 2 depicts the proposed system architecture, discriminating between an aggregation scheme and a reasoning scheme. In this respect, let us consider that the architecture comprises of h SRS-based signal detection methods denoted by the set:

SR = {SR 1 , SR 2 , . . . , SR h }, (1)
j methods appropriate for signal detection in structured longitudinal observational healthcare data sources corresponding to:

OD = {OD 1 , OD 2 , . . . , OD j }, (2)
and k detection methods for unstructured text sources denoted as:

UT = {U T 1 , U T 2 , . . . , U T k }. (3)
The architecture includes also means to access l ADR reference data sources:

RS = {RS 1 , RS 2 , . . . , RS l }, (4)
as well as m drug information sources:

DI = {DI 1 , DI 2 , . . . , DI m }. (5)
O depicted in Figure 2 -Drug Information Agent: an information retrieval agent capable of identifying supportive information for the outcomes of the Signal Ranking Agent.

According to the behaviour that the above agent classes have to exhibit, we addressed design issues at the micro-level. For example, the Aggregation Agent encapsulates a rule-based logic, in order to implement the agent coordination protocol, while wrapper agents (i.e. the Methods Selection Agent and Signal Detection Agents) incorporate a translation mechanism capable of converting agent requests to queries in the respective resources and encapsulating the obtained results in an agent message.

Upon a new experiment definition, instances of the above agent classes are launched to undertake the corresponding signal detection workflow 5 .

The behaviour of each agent is presented in the description of the aggregation and reasoning schemes, in subsections 3.3 and 3.4, respectively.

Selection of Methods and Aggregation of Outcomes

The proposed platform aims to support two diverse usage scenarios, i.e.: (a) signal detection without a specific target on drugs or health outcomes, which is performed routinely by drug safety authorities, and (b) targeted signal detection concerning specific drugs and potential adverse effects, which is particularly interesting for pharmaceutical companies as a mean to identify risks for their marketed drugs.

Upon the definition of a new analysis experiment, in the targeted signal detection scenario the user provides as input the target of the analysis (drug and/or health outcome of interest). In addition, in both scenarios, optional input parameters can be: (a) the resources that will be employed in the experiment (i.e. the sources of pharmacovigilance signals, the reference data sources on known ADRs and the drug information sources), (b) specific values of analysis/configuration parameters offered by signal detection methods, such as the rule for signal generation 6 , the time-at-risk7 , etc., and (c) ranking criteria to be employed for the prioritisation of the generated signals. If the above optional input parameters are not defined, then: (a) all the resources available in the platform will be employed, (b) the default values for analysis/configuration parameters defined for each signal detection method will be used, and (c) all the available ranking criteria will be employed, respectively.

Although explicit, the above inputs pose also implicit requirements (e.g. which methods can support the signal generation criterion) for the experiment that will be conducted. Based on these inputs, the selection of the signal detection methods that will be used in a given signal detection experiment is performed by querying the Semantic Registry O (Fig. 2). O defines the capabilities, interfaces and parameterisation options of each signal detection method, according to expert domain knowledge and the specifications provided by the respective developers. The respective query is forwarded to the Methods Selection Agent by the Aggregation Agent, given the input parameters provided by the User Agent.

In particular, let C denote the set of input parameters that the user defined for a given experiment:

C = {C 1 , C 2 , . . . , C q }, (6)
and assume that C is met by a set of n detection methods:

P = {P 1 , P 2 , . . . , P n }, (7)
with P denoting a subset of the available ones, i.e. P ⊆ (SR ∪ OD ∪ UT). In particular, P is determined by applying a matchmaking query Q, between the input parameters C and the registered detection methods in O, through the Methods Selection Agent:

Q : C O -→ P. (8)
According to P, the corresponding Signal Detection Agents are requested by the Aggregation Agent to invoke the respective signal detection methods, taking into account potential input parameters defined in [START_REF] Kelman | Evaluating medicines: let's use all the evidence[END_REF]. The analysis results obtained from each Signal Detection Agent are gathered by the Aggregation Agent, and correspond to a set R, with:

R = {R 1 , R 2 , . . . , R n }, (9)
where R i , i = {1, . . . , n} denotes in turn a set of potential signals obtained from the P i detection method [START_REF] Trifirò | Data mining on electronic health record databases for signal detection in pharmacovigilance: which events to monitor?[END_REF]. In addition, elements of R may be equal to ∅, in case where no indication for signals is obtained by the respective detection method(s). Next, the Aggregation Agent encodes the obtained outcomes R into a uniform representation, keeping also provenance information (i.e. which methods and data were employed and with what parameter values) regarding the origin of each R i .

Filtering, Prioritisation and Annotation of Outcomes

This part concerns the reasoning scheme, employing the available reference ADR and drug information sources, i.e. RS (4), DI (5), respectively, in order to: (a) filter R (9) for noisy indications and, subsequently, (b) prioritise the remaining novel indications (if any), according to ranking criteria. In this regard, first, the Aggregation Agent provides its results to the Filtering Agent, which implements a novelty assessment mechanism f1, so that from each R i a subset R i (R i ⊆ R i ) is produced containing only the novel indications:

f1 : R RS -→ R . ( 10
)
As a second step, the Aggregation Agent provides R to the Signal Ranking Agent, which is in turn capable of applying a prioritisation mechanism f2 on R based on a set of metrics that is denoted as:

PR = {P R 1 , P R 2 , . . . , P R w }. (11)
In PR, we discriminate two types of metrics/criteria:

1. computational metrics, e.g. prioritising the common results within the first k among those provided by the signal detection methods employed in a given analysis experiment, and 2. domain criteria, like those proposed for implementing triage schemas in signal detection [START_REF] Lindquist | Use of triage strategies in the WHO signaldetection process[END_REF], e.g. ADR seriousness, newer drugs, data originated from multiple countries, etc.

The information to apply domain criteria may be found either in drug information sources (e.g. the drug release date), or in the raw data employed for signal detection. As an example of the latter case, spontaneous reports typically contain a characterisation of the reported event as serious or not, and may further specify seriousness according to the result (e.g. death, life threatening condition, hospitalisation, etc.). Thus, the Signal Ranking Agent embodies the required knowledge, in order to interpret such domain criteria. Let us consider that the end-user defined in C (6) a set of ranking metrics PR (with PR ⊆ PR) to be applied in a given experiment.

Then, R # corresponds to the ranking of R based on PR , i.e. R # ≡ rank(R )|PR , by applying f2, i.e.:

f2 : R PR -→ R # . ( 12
)
The final outcome FO provided to the end-user via the User Agent comprises of R # along with support information obtained from the Drug Information Agent through DI per R # element, if available, i.e.:

FO = R # ∪ DI R # . (13)
Figure 3 illustrates via a sequence diagram the collaborative agent interaction protocol implementing the above signal detection strategy within the integrated framework.

Implementation and Example Scenario

Material

At the current stage, the development of the proposed integrated signal detection framework relies on publicly available resources. In particular, we employed the following: -Sources of raw data for signal detection: (a) the FAERS spontaneous reporting system; (b) PubMed, the reference bibliographic database in the life sciences, and (c) Twitter, a popular micro-blogging platform. -Reference data sources for filtering the outcomes of signal detection methods: (a) the Side Effect Resource (SIDER) [START_REF] Kuhn | A side effect resource to capture phenotypic effects of drugs[END_REF], containing information on marketed medicines and their recorded ADRs, which is extracted from public documents and package inserts, and (b) DrugBank [START_REF]The DrugBank database[END_REF], since it provides rich information on drug-drug interactions. Both SIDER and DrugBank provide also the indications for each drug's use, which is another type of information employed for filtering. -Drug information sources for supporting evidence on novel findings: (a) ChEMBL [START_REF]The ChEMBL database[END_REF], which contains 2-D structures, calculated properties and abstracted bioactivities of drugs, but also (b) DrugBank, as it combines drug data (i.e. chemical, pharmacological and pharmaceutical) with comprehensive drug target information (i.e. sequence, structure, and pathway), along with biointeraction information. -Signal Detection Methods: implementations of wellknown methods contained in the open-source PhViD R package [START_REF] Ahmed | PhViD: An R package for Phar-macoVigilance signal Detection[END_REF], and an in-house signal detection method appropriate for unstructured text. -Semantic Registry: PV-SDO [START_REF] Koutkias | Leveraging postmarketing drug safety research through semantic technologies: the PharmacoVigilance Signal Detectors Ontology[END_REF], an ontology expressed in OWL2 (Web Ontology Language 2) [START_REF]OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax[END_REF], and populated with sample signal detection method implementations, and the reference drug data and information resources mentioned above.

While further resources will be elaborated in subsequent stages of this development, the above material has been considered adequate for a proof-of-concept prototype implementation.

Development Aspects

Access to the resources mentioned in subsection 4.1 has been realised programmatically. In particular, FAERS data are retrieved through the openFDA Application Programming Interface (API) [START_REF]The openFDA Drug API[END_REF], access to PubMed data relies on the Web services provided by Europe PubMed Central [START_REF][END_REF], and Twitter posts are retrieved through the available REST (Representational State Transfer) APIs [START_REF]The Twitter REST APIs[END_REF]. Access to SIDER, DrugBank and ChEMBL is made through the SPARQL (SPARQL Protocol and RDF Query Language) endpoints [START_REF]SPARQL 1.1 Overview, W3C Recommendation[END_REF], available from Bio2RDF [51].

The multiagent system implementation is based on the Java Agent DEvelopment framework (JADE) [START_REF]Java Agent DEvelopment framework (JADE[END_REF], providing besides open source development tools, the necessary agent execution environment. JADE is compliant with the specifications for interoperable multiagent systems released by the Foundation for Intelligent Physical Agents (FIPA) [START_REF]The Foundation for Intelligent Physical Agents (FIPA)[END_REF].

Signal Detection Agents invoke the respective signal detection methods via Rserve [START_REF]Rserve -Binary R server[END_REF], a TCP/IP server allowing for third-party software to use R from various languages and without the need to initialise R or link against the R library. Upon initiation, each Signal Detection Agent is registered with the Directory Facilitator, a standard agent contained in the FIPA Abstract Architecture [START_REF]Foundation for Intelligent Physical Agents, FIPA Abstract Architecture Specification, SC00001L[END_REF], which provides "yellow page" services for the agents of the platform. Thus, the Aggregation Agent queries the JADE built-in Directory Facilitator to obtain the list of relevant Signal Detection Agents, according to the analysis scenario.

In the current prototype, knowledge embodied in the Signal Ranking Agent for the application and interpretation of domain criteria used for signal ranking, such as seriousness, is represented via a set of simple rules (e.g. to encode that death is more severe than hospitalisation). Although this is a rather simplistic approach, a generic resource providing this kind of knowledge is not currently available.

Agent communication relies on message exchange. Messages are represented in the relevant FIPA standards for agent communication, which set out the encoding, the semantics and the pragmatics of messages. In this regard, messages are structured according to the FIPA ACL Message Structure Specification [START_REF]Foundation for Intelligent Physical Agents, FIPA ACL Message Structure Specification[END_REF], and are built upon the FIPA Communicative Act Library (e.g. request, inform, agree, etc.) [START_REF]Foundation for Intelligent Physical Agents, FIPA Communicative Act Library Specification[END_REF]. The messages' content relies on FIPA-SL [START_REF]Foundation for Intelligent Physical Agents, FIPA SL Content Language Specification[END_REF], and on a basic application ontology that we defined. This JADE-specific ontology contains the respective agent actions and the predicates to facilitate agent communication, according to the methodology proposed in JADE and using the Ontology BeanGenerator tool [START_REF] Caire | JADE Tutorial: Application-defined Content Languages and Ontologies[END_REF].

While various open-source implementations of signal detection methods are available for SRS and structured observational data, the availability of implementations for unstructured text-based signal detection methods is limited for the moment. Thus, we developed a simple signal detection method relying on the clinical Text Analysis and Knowledge Extraction System (cTAKES) [START_REF]The clinical Text Analysis and Knowledge Extraction System (cTAKES)[END_REF], and on its built-in Unified Medical Language System (UMLS) [START_REF]The Unified Medical Language System (UMLS)[END_REF] Annotator, to identify drugrelated terms and effects within PubMed abstracts and Twitter posts (namely, VigiText). Notably, cTAKES is built upon the Unstructured Information Management Architecture (UIMA) [START_REF]The Unstructured Information Management Architecture (UIMA)[END_REF], thus, the development of VigiText follows an established standard for managing unstructured data.

We illustrate the functionality of the proposed multiagent system via the following example signal detection scenario.

Example Scenario

Let us focus on a targeted signal detection scenario and assume that the proposed platform integrates through its multiagent system the following signal detection methods8 :

-SRS-based detection methods9 : BCPNN, GPS, PRR, and ROR. -Observational data detection methods10 : ICTPD and

LGPS.

-Unstructured text detection methods: VigiText.

In this case, (1)-( 3) correspond to: SR = {BCPNN, GPS, PRR, ROR}, OD = {ICTPD, LGPS}, and UT = {VigiText}, respectively. Also, the Filtering Agent is capable of querying Drug-Bank and SIDER, in order to filter the obtained outcomes from known ADRs and findings that correspond to the drug's indicated use, while the Drug Information Agent can connect to ChEMBL and DrugBank, in order to obtain complementary drug information. Thus, in the scope of this scenario, (4)-( 5) correspond to: RS = {SIDER, DrugBank} and DI = {ChEMBL, DrugBank}, respectively.

A safety expert working for a pharmaceutical company wishes to search for potential signals concerning Drug X, a new drug of the company which has been quite recently made available in the market. Thus, (s)he employs the resources of the platform to analyse data from an observational healthcare database and the reports available in FAERS. The user is prompted by the User Agent to provide the input for this analysis (cf. subsection 3.3). Besides Drug X, let us consider that (s)he defines for SRS-based detection methods the decision rule for signal generation to be "more than 3 reports", while for the OD-based detection methods (s)he sets the value of the "Time-at-risk" parameter to be "lengthof exposure+30days". Thus, (6) can be rewritten as: C = {T arget="Drug-X", M ethods="SR, OD", SR Analysis Criterion : Signal generation condition=">3 reports", OD Analysis Criterion : Time-at-risk="length of exposure+30days"}.

Assuming that the considered ICTPD implementation does not support the defined value for Time-at-risk, a fact that is captured in the PV-SDO ontology, ICTPD is implicitly excluded from the analysis experiment as indicated by the Methods Selection Agent. Thus, (9) corresponds to:

P = {BCPNN, GPS, PRR, ROR, LGPS}.
Launching a Signal Detection Agent for each detection method of P, let us assume that the aggregation outcome given by ( 9) for the targeted Drug X is:

R = {R BCPNN , R GPS , R PRR , R ROR , R LGPS }, with 11 : R BCPNN = {Drug X-MI,Drug X-Neutropenia}, R GPS = {Drug X-MI}, R PRR = ∅, R ROR = {Drug X-ARF} and R LGPS = {Drug X-MI}.
The Filtering Agent performs SPARQL queries to DrugBank and SIDER such as the one presented in Fig. 4, in order to identify which of the above indications shall be discarded. Let us assume that MI is a registered ADR for Drug X in both DrugBank and SIDER. Thus, it is discarded from R. As a result, R comprises of:

R BCPNN = {Drug X-Neutropenia} and R ROR = {Drug X-ARF}, while R GPS = R PRR = R LGPS = ∅.
In order to prioritise the remaining indications, i.e. Neutropenia and ARF, the user selects to employ the ADR seriousness criterion, i.e. PR = {Seriousness}. Assuming that ARF appears to result in more serious effects than Neutropenia in the analysed data (e.g. more deaths have been reported with ARF), as provided by the Signal Ranking Agent, Drug X-ARF is ranked prior to Drug X-Neutropenia, i.e.: R # = {Drug X-ARF, Drug X-Neutropenia}.

Finally, the Drug Information Agent obtains the entire biochemical profile of Drug X and its biointeractions by querying ChEMBL and DrugBank, respectively. This information is attached to R # to formulate the final outcome FO as in [START_REF] Koutkias | Computational approaches for pharmacovigilance signal detection: toward integrated and semantically-enriched frameworks[END_REF], also annotated with provenance information for the experiment.

For illustration purposes, the above scenario refers to fictitious data and it is rather oversimplified, since typically the outcome of a signal detection method returns a long list of drug-event pairs, which shall be further considered for a potential causal relation. Nevertheless, it provides a comprehensive view of the agent interaction protocol and the scope of integrated signal detection that we introduced in this paper.

Notably, taking advantage of the proactive nature of agents [START_REF] Singh | Service-Oriented Computing: Semantics, Processes[END_REF], the above drug safety screening scenario may be executed as a background process. In this respect, the user is notified promptly as soon as indications for signals are identified. Similarly, in the scenario of screening for signals without a specific target, the process shall be iteratively executed, when new data become available.

Discussion

Contribution of this Work

This study elaborated on the design and development of advanced IT mechanisms to leverage pharmacovigilance signal detection. Timely and accurate signal detection is of outmost importance in the scope of an active drug surveillance system [START_REF] Norén | Modern methods of pharmacovigilance: detecting adverse effects of drugs[END_REF]. A number of quite recent, very significant drug safety issues illustrated that adverse effects of drugs may be detected too late, when millions of patients have already been exposed. To this end, the investigation of diverse data sources via different analysis methods for signal detection can contribute in more timely and accurate findings [START_REF] Kelman | Evaluating medicines: let's use all the evidence[END_REF].

In accordance with this perspective, the current work introduced integrated signal detection, i.e. jointly exploiting multiple heterogeneous signal detection methods, data and other drug-related resources under a com-mon framework, in order to strengthen the reliability and coverage of the analysis outcomes. Besides outcomes' aggregation, the proposed approach included their filtering, ranking and annotation, aiming to support drug safety experts in assessing and prioritising the results. To this end, we take into account both computational metrics and domain criteria in order to prioritise the findings, while we also seek existing knowledge for filtering noisy indications from relevant linked-data based repositories.

Our research was built upon current systematic efforts in the field, as we relied on available implementations of signal detection methods, as well as publicly available drug safety related data and resources. The idea of exploring and comparing different types of pharmacovigilance signal detection methods has been pinpointed in the literature [START_REF] Harpaz | Combing signals from spontaneous reports and electronic health records for detection of adverse drug reactions[END_REF], [START_REF] Liu | Large-scale prediction of adverse drug reactions using chemical, biological, and phenotypic properties of drugs[END_REF]. However, we elaborated on a systematic framework aiming to explore this perspective at large-scale.

The multiagent system that has been proposed provides the basis for developing a platform to conduct integrated signal detection. We defined a collaborative agent integration protocol, in order to coordinate agent activities and implement the workflow for integrated signal detection. Thanks to the modularity and scalability offered by the agent paradigm [START_REF] Isern | Agents applied in health care: a review[END_REF], we are able to replicate our current approach and extend its capabilities by integrating additional detection methods in the platform.

Related Work

In the field of drug safety surveillance, various systematic initiatives have been recently formulated. In particular, the FDA-funded Mini-Sentinel project elaborates on designing safety assessments using multiple existing electronic healthcare data systems, developing and evaluating scientific methods to increase the precision of detection techniques, while also identifying and address-ing barriers and challenges to build an advanced system for active safety surveillance [66]. Similarly, OMOP implemented and evaluated signal detection methods for longitudinal observational data [START_REF]The Observational Medical Outcomes Partnership[END_REF]. More recently, the Observational Health Data Sciences and Informatics (OHDSI) program has been established as a multistakeholder, interdisciplinary collaborative to bring out the value of health data through large-scale analytics [START_REF]Observational Health Data Sciences and Informatics (OHDSI) program[END_REF].

In addition, the EU-ADR Web Platform relies on the exploitation of EHR data collected within a largescale European initiative [START_REF] Oliveira | The EU-ADR web platform: delivering advanced pharmacovigilance tools[END_REF]. Data are mined for specific drug events, which are then correlated with literature, protein and pathway data, resulting in a rich drugevent dataset. Advanced distributed computing methods based on workflow technologies are tailored to coordinate the execution of data-mining and statistical analysis tasks.

Contrary to the above-mentioned important initiatives, we consider signal detection in an integrative framework that involves multiple heterogeneous data sources and detection methods, rather than focusing on a specific method applied on multiple sources of the same kind, or on diverse methods applied on a specific data source for benchmarking [START_REF] Koutkias | Computational approaches for pharmacovigilance signal detection: toward integrated and semantically-enriched frameworks[END_REF]. In this respect, we adopted the agent paradigm as the enabling technology for the development of an integrated platform, due to its proactive, reactive and social nature. These features enabled us to design and implement a novel collaborative multiagent system for signal detection, relying on appropriate mechanisms to automate and improve existing tasks [START_REF] Luck | A manifesto for agent technology: towards next generation computing[END_REF], that drug safety experts typically have to undertake manually.

The agent paradigm has been successfully employed in healthcare in various cases [START_REF] Isern | Agents applied in health care: a review[END_REF], with applications spanning from decision support systems [START_REF] González-Vélez | Healthagents: distributed multi-agent brain tumor diagnosis and prognosis[END_REF], disease monitoring [START_REF] Bromuri | Monitoring Gestational Diabetes Mellitus with Cognitive Agents and Agent Environments[END_REF], telehealth services [START_REF] Koutkias | A multiagent system enhancing home-care health services for chronic disease management[END_REF], ambient intelligence and independent living [START_REF] Kaluža | A multi-agent care system to support independent living[END_REF], integration of heterogeneous biomedical systems [START_REF] Koutkias | Engineering agent-mediated integration of bioinformatics analysis tools[END_REF], cross-organisational workflow management [START_REF] Bouzguenda | Dynamic medical crossorganizational workflow management system[END_REF], planning and resource allocation [START_REF] Cortés | UCTx: a multi-agent system to assist a transplant coordination unit[END_REF], to evaluation of medical systems [START_REF] Tian | Use of an agent-based simulation model to evaluate a mobile-based system for supporting emergency evacuation decision making[END_REF]. Via this work, we illustrate a new application domain of agent technologies in life sciences, i.e. pharmacovigilance.

To the best of our knowledge, an agent-based perspective on the domain of drug safety has been only explored in [START_REF] Ji | A distributed adverse drug reaction detection system using intelligent agents with a fuzzy recognitionprimed decision model[END_REF], in which a multiagent framework was proposed for early detection of ADRs using electronic patient data distributed across different sources and locations. The framework relied on intelligent agents employing fuzzy logic to represent, interpret, and compute imprecise and subjective cues that are commonly encountered in ADR identification, as well as to retrieve prior experiences by evaluating the extent of matching between the current situation and a past experience. Contrary to [START_REF] Ji | A distributed adverse drug reaction detection system using intelligent agents with a fuzzy recognitionprimed decision model[END_REF], in the current paper we introduced an agent-based approach for the joint exploitation of multiple, diverse and existing signal detection methods, which are designed to analyse different types of signal sources, under an integrated framework.

From a technical perspective, given that the proposed multiagent system relies on semantic resources, a notable work is the BioSTORM system [START_REF] Nyulas | An ontologydriven framework for deploying JADE agent systems[END_REF]. BioS-TORM elaborated on ontology-based, end-to-end deployment of JADE-based agent systems by exploiting diverse surveillance methods. While BioSTORM shares some architectural similarities with the proposed system, it was created for a different purpose/domain than drug safety that was our focus. In terms of its general rationale, our system shares some common attributes with the DeepQA architecture [START_REF] Ferrucci | Building Watson: an overview of the DeepQA project[END_REF]. DeepQA exploits multiple methods for analysing natural language, identifying sources, finding and generating hypotheses, finding and scoring evidence, as well as merging and ranking hypotheses. Nevertheless, DeepQA is a general-purpose massively parallel probabilistic evidence-based architecture having its focus on unstructured/free-text data based on UIMA, while our work relies on both structured and unstructured resources focusing on a specific application domain.

Challenges and Future Work

Using a first prototype, we are currently elaborating on particular case studies to illustrate the added value of the proposed approach. Defined in collaboration with drug safety experts, these studies concern drugs and adverse effects that are quite rare, as well as new drugs placed in the market, e.g. new anticoagulants, and their association with specific adverse effects. In this regard, the preliminary analysis reveals some "echoing" findings across the diverse data sources explored, i.e. the same signals are discovered in multiple data sources and by multiple detection methods. This may indicate the means of strengthening the outcomes provided by signal detection methods applied separately, since replicated signals obtained from diverse methods and data sources may indicate more probable causal associations between drugs and adverse effects.

Given the uncertainty of the results that signal detection methods provide, approaches for fusing knowledge under uncertainty are being investigated [START_REF] Santos | Fusing multiple Bayesian knowledge sources[END_REF]. We are also considering an agent-based voting scheme [START_REF] He | A boost voting strategy for knowledge integration and decision making[END_REF], which will enable us to pursuit signal prioritisation by applying multiple ranking criteria and measuring the strength of signals in a comparative fashion. Overall, combining methods and their results in order to improve accuracy, confidence, or speed such as the approach employed in DeepQA [START_REF] Ferrucci | Building Watson: an overview of the DeepQA project[END_REF], is a part of the developed system that requires further research.

In terms of development, we find the potential to assess whether BioSTORM could be applicable in the particular application domain interesting [START_REF] Nyulas | An ontologydriven framework for deploying JADE agent systems[END_REF]. In addition, in the current implementation, the Signal Detection Agents are handling the R output of the respective detection methods. Signal detection methods exposed through standardised, machine readable interfaces, would provide a more systematic solution. To this end, we explore comprehensive frameworks for integrating R code in third-party applications, such as DeployR [82]. Enriching and advancing the knowledge according to which the Signal Ranking Agent applies domain criteria, requires further research and development.

Up to now, we experimented with signal detection methods that are available in the PhVid R package [START_REF] Ahmed | PhViD: An R package for Phar-macoVigilance signal Detection[END_REF]. Further methods will be integrated in the subsequent implementation phase, such as those contained the OMOP Methods Library [START_REF]The OMOP Methods Library[END_REF]. Along this line, we aim to elaborate on additional data sources for signal detection and, particularly work with structured observational data. We are also elaborating on mechanisms for social media screening, since patient self-reports may provide unique insights, especially for drugs used in the treatment of rare diseases, the feedback for which is limited.

In the scope of active drug safety surveillance [START_REF] Norén | Modern methods of pharmacovigilance: detecting adverse effects of drugs[END_REF], signal detection is a continuous and demanding process. From the computational viewpoint, taking into account the complexity posed by jointly exploiting multiple signal detection methods and drug-related resources under the integrated signal detection approach that we introduced, deploying and executing the proposed multiagent system in a cloud infrastructure is being considered as a future step [START_REF] Burian | Multi-agent systems and cloud computing for controlling and managing chemical and food processes[END_REF]. This would accommodate the required power, reliability and scalability for a large-scale deployment accounting for additional signal detection methods and drug safety resources.

Conclusions

deep This paper illustrated the application of the multiagent paradigm for systematically pursuing pharmacovigilance signal detection within an integrated framework. A formal agent collaboration strategy was proposed, taking into account methods' selection, aggregation of methods' outcomes, and subsequently filtering known ADRs and ranking the remaining potential signals for prioritisation. Relying on various data, information and knowledge sources along with a number of signal detection method implementations, our proof-ofconcept development illustrated that the agent-based approach is valid for such an integration. We are currently elaborating to integrate further resources and illustrate the added value in signal detection through concrete case studies. Overall, this work constitutes a step toward large-scale, knowledge-intensive computational signal detection.

Fig. 1

 1 Fig. 1 Elaborated workflow for integrated signal detection.

Fig. 2

 2 Fig.2The proposed system architecture for integrated signal detection.

  denotes the ontology-based Semantic Registry of Signal Detection Resources [34]. The following agent classes were defined: -User Agent: an interface agent responsible to support the end-user in defining and conducting an integrated signal detection experiment. -Aggregation Agent: a mediator agent which controls the agent interaction protocol. -Methods Selection Agent: a wrapper agent which queries O for appropriate signal detection methods given a specific experiment. -Signal Detection Agent: a wrapper agent capable of receiving requests for signal detection (along with specific analysis parameters), launching the respective signal detection method, and returning the outcomes 4 . -Filtering Agent: a processing agent capable of accessing ADR reference sources, in order to filter the aggregated outcome provided by Signal Detection Agents.-Signal Ranking Agent: a processing agent capable of applying diverse criteria/metrics, in order to rank the results provided by the Filtering Agent.

Fig. 3 A

 3 Fig.3A partial view of the elaborated agent interaction protocol (for simplicity, only agents are depicted).

Fig. 4

 4 Fig.4Indicative SPARQL query to assess whether Myocardial Infarction is a known ADR for drug X.

For a list of comprehensive definitions in the domain of pharmacovigilance the reader is referred to[START_REF] Linguist | The need for definitions in pharmacovigilance[END_REF].

ADR: response that is noxious and unintended, and that occurs at doses normally used in humans for the prophylaxis, diagnosis, or therapy of disease, or for the modification of physiological function[START_REF] Linguist | The need for definitions in pharmacovigilance[END_REF].

An indicative example concerning the variety of analysis options is illustrated in[START_REF] Stang | Variation in choice of study design: Findings from the epidemiology design decision inventory and evaluation (EDDIE) survey[END_REF], in which 14 signal detection methods were tested and the number of different combinations of analysis parameters varied

from 48 to 162.

Note that for each one of the considered computational methods (1)-(3), a Signal Detection Agent is assigned.

This practice has been followed in the current experimental implementation. However, it is also possible to share agent instances across experiments (such as the Drug Information Agent, the Filtering Agent, the Signal Ranking Agent, etc.).

[START_REF] Kelman | Evaluating medicines: let's use all the evidence[END_REF] A condition or a set of conditions that needs to be satisfied by a signal detection method, in order to generate a

signal.[START_REF] Trifirò | Data mining on electronic health record databases for signal detection in pharmacovigilance: which events to monitor?[END_REF] The period of time a patient is considered to be 'at-risk' and, therefore, counting occurrence of conditions as potential events.

For the sake of simplicity and for illustration purposes, we consider a limited number of detection methods and refer to fictitious data in this example.

Methods contained in[START_REF] Ahmed | PhViD: An R package for Phar-macoVigilance signal Detection[END_REF]. BCPNN: Bayesian Confidence Propagation Neural Network, GPS: Gamma Poisson Shrinkage, PRR: Proportional Reporting Ratio, ROR: Reporting Odds Ratio.

[START_REF] Harpaz | Novel data mining methodologies for adverse drug event discovery and analysis[END_REF] Methods available at[START_REF]The OMOP Methods Library[END_REF]. ICTPD: Information Component Temporal Pattern Discovery, LGPS: Longitudinal Gamma Poisson Shrinkage.

ARF: Acute Renal Failure, MI: Myocardial Infarction.

Acknowledgements This research was supported by a Marie Curie Intra European Fellowship within the 7th European Community Framework Programme FP7/2007-2013 under REA grant agreement n o 330422 -the SAFER project.

The authors would like to express their appreciation to the reviewers for their constructive comments and suggestions.

Conflict of interest

The authors declare that they have no conflicts of interest.