K I Gómez

Sotelo * C Baron

* P Esteban

C Y A Gutiérrez Estrada

J L De

Laredo Velázquez

How to find non-functional requirements in system developments

Keywords: Systems engineering, requirements, non-functional requirements, requirement taxonomy.  

The current complexity of systems requires a full understanding of stakeholder needs in system design. Later, these needs will become requirements of the system: functional requirements are quite easy to describe for the customer, but finding the non-functional requirements is an actual challenge; however, they are essential to design the system. The objective of this research work is to provide support when defining non-functional requirements. The proposal consists in a requirement classification and a questionnaire that progressively guides the elicitation of stakeholder needs. This method is applied to three case studies, demonstrating its interest and indicating opportunities for improvement.

INTRODUCTION

Engineering Science aims at improving people's life quality through problem solution [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF]. However problems do not generally have an easy nor a unique solution. This is where Systems Engineering is valuable, because of its wide vision of the problem in a systemic approach [START_REF] Kossiakoff | Systems engineering: principles and practice[END_REF]. It guides the development processes with a systemic point of view: identifying all the stakeholders and their needs, deriving them into system requirements, designing and evaluating several possible technical options to meet the requirements, till the selection of one solution [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF]. Authors like [START_REF] Hickey | Elicitation technique selection: how do experts do it[END_REF]Davis (2003) Faisandier (2012), [START_REF] Blanchard | Systems Engineering and analysis[END_REF] and SEBoK (2017) recommend to consider several methods and techniques during elicitation and identification of stakeholder needs, expectations, and requirements, this is to better accommodate the diversity of the sources and situations. However, when analyzing the industrial practices and the causes of projects failures [START_REF] Oehmen | The guide to lean enablers for managing engineering programs[END_REF], it is realized that the actual stakeholder needs and the quality characteristics that the stakeholders want to meet are too often pre-assumed or misunderstood [START_REF] Faisandier | System Notion and Engineering of Systems[END_REF]. Several authors [START_REF] Blanchard | Systems Engineering and analysis[END_REF][START_REF] Kiritani | The success or failure of the requirements definition and study of the causation of the quantity of trust existence between stakeholders[END_REF] stress the importance to make additional efforts on the system requirement definition stage, in order to ensure the effectiveness of decision making in the design process. Kritani and Ohashi (2015), specify that "the quality of requirements definition directly leads to the final success or failure of system development project". In accordance to [START_REF] Oehmen | The guide to lean enablers for managing engineering programs[END_REF] the issue of unstable, unclear and incomplete requirements stands second in the themes of challenges in managing engineering programs, because it seriously affects the program efficiency and effectiveness. Thus, a first conclusion is that precisely and completely identifying the needs is a tricky issue, but a crucial step that has a fantastic impact on the whole development process and the project success. This issue must be methodologically addressed and the requirement elicitation process must be thoroughly guided. Requirements are generally classified in two distinct groups: functional and non-functional [START_REF] Glinz | Rethinking the notion of non-functional requirements[END_REF][START_REF] Badreau | Ingénierie des exigences méthodes et bonnes pratiques pour construire et maintenir un référentiel[END_REF][START_REF] Mabrok | Integrating nonfunctional requirements into axiomatic design methodology[END_REF]. This paper thus focuses on non-functional requirements in priority. The objective is to provide help to the analysis and design teams to determine non-functional requirements. To reach this goal, are established a requirement taxonomy and a questionnaire, in order to guide the elicitation of needs and the requirements identification process. The method is applied to three case studies from which some conclusions and perspectives are derived. Section 2 presents the literature review. Section 3 proposes a classification of requirements and the questionnaire. Section 4 illustrates the method applied on case studies. Section 5 concludes on the interest of the proposal and gives future perspectives.

LITERATURE REVIEW

In order to be clear, it is necessary to start with some definitions that will help the reader to understand Systems Engineering philosophy, on which this research work has been carried out.

Systems Engineering & Requirements

Systems Engineering (SE) can be described as an "interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life." (ISO/IEC/IEEE, 2017, p. 457). The SE holistic vision suggest studying problems through a contextual analysis of the situation, exhaustively gathering the needs and later translating them into technical requirements, which will define the possible characteristics of a future system. In that way, the SEBoK (2017) defines SE as "a pragmatic approach, inherently interdisciplinary, yet specialized". According to [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF], Requirements Engineering (RE) can be considered as a part of SE activities. RE "is concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting and managing requirements". (ISO/IEC/IEEE, 2017, p. 381). This paper focuses on Requirements Engineering. Its contribution consists in the proposal of a requirements taxonomy and a questionnaire to provide support during the identification of stakeholder needs and requirements.

Needs and requirements

Literature offers several definitions of needs and requirements. According to [START_REF] Ryan | On the definition of terms in a requirements expression[END_REF] "needs are typically considered to be expectations stated in the language of those at the business management level or of stakeholders at the business operations level. Requirements are considered to be formal statements that are structured and can be verified and validated". The purpose of translating needs is to transform a natural language expression into a more formal one, as clearly as possible, and without introducing any bias. The set of requirements will be useful to assess if the system meets the requirements, and to validate that the system meets the needs. Requirements have been classified through time and in different ways; but, which is the purpose of classifying requirements?

Requirement classifications

According to [START_REF] Palmer | Classification as an approach to requirements analysis[END_REF], requirement classifications are helpful as an approach for problem solving and requirement analysis, and to detect conflict among requirements. They may be applied to complex tasks as verification and validation. [START_REF] Sommerville | Viewpoints for requirements elicitation: A Practical Approach[END_REF] propose an approach to organize system requirements to provide a support for requirement elicitation; their approach identify the concerns (goals) which affect the system, derive a set of questions to assure that the information required will satisfy the concerns (essential information and constraints), and finally elicit and negotiate the requirements which ensure that the system will satisfy the identified concerns. [START_REF] Ryan | On the definition of terms in a requirements expression[END_REF], [START_REF] Faisandier | System Notion and Engineering of Systems[END_REF], and SEBoK (2017) highlight that the importance of these requirement classifications lies in that they allow taking all kinds of requirements in consideration. Authors like [START_REF] Glinz | Rethinking the notion of non-functional requirements[END_REF], [START_REF] Badreau | Ingénierie des exigences méthodes et bonnes pratiques pour construire et maintenir un référentiel[END_REF] and [START_REF] Mabrok | Integrating nonfunctional requirements into axiomatic design methodology[END_REF] classify system requirements in two groups: 1) Functional requirements (FRs): they describe the expected services, what a system is supposed to or should do [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF]. 2) Non-functional requirements (NFRs): they are essential in the design process because they determine the technical specifications of the product that will be delivered; they impose constraints and capture the properties to operate the system; they also describe the non-behavioral aspect of the system [START_REF] Mabrok | Integrating nonfunctional requirements into axiomatic design methodology[END_REF]. According to SEBoK (2017) they are the quality characteristics or attributes that define how is supposed to be a desired system. Both, FRs and NFRs are needed in the design process: the first ones to satisfy the need in functionality, the seconds to make the system possible and to satisfy the non-functional user expectations. FRs often are considered as the most important requirements, because they define the systems functionalities, and less attention is paid to NFRs. However, researchers have recently argued that there is no underlying theory to answer "why we ought to consider function as the most fundamental aspect of engineering design" [START_REF] Mabrok | Integrating nonfunctional requirements into axiomatic design methodology[END_REF]. Considering FRs and NFRs with the same importance will allow the analysis and design team to make sure that the selected design satisfy (or not) both type of requirements. Beyond this distinction between functional and non-functional requirements, several sub-classifications of NFRs themselves can be found in literature. However, they can differ. Indeed, [START_REF] Glinz | Rethinking the notion of non-functional requirements[END_REF] expresses that there is no consensus of "what a non-functional requirement really is", and the author adds that there are divergent concepts for subclassifying NFRs.

Non-functional requirement classifications

Among the sub-classifications of NFRs, [START_REF] Glinz | Rethinking the notion of non-functional requirements[END_REF] proposes a requirement classification based on four facets: kind, satisfaction, representation, and role. [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF] and SEBoK (2017) proposes to classify the requirements by "type", that means "the nature of the requirement itself" (SEBoK, 2017). Lately, some authors have done interesting propositions, considering new kinds of non-functional requirements: a) [START_REF] Grispos | Are you ready? Towards the engineering of forensic-ready systems[END_REF] mention that in the past few years, researchers have proposed to integrate what they call "forensic requirements" during system development, related to the detection, investigation, eradication and recovery of incidents. However, the authors express that techniques for eliciting and analyzing these forensic requirements have not actually been proposed in the literature. b) Ryan ( 2014) talks about the "end of life" versus the "end of life cycle" of a system; the author proposes that the system design should focus on the system retirement stage to include requirements related to the transition between the different life cycles of the system. The author suggests considering several elements during the system concept stage: a) the reasons for system retirement, b) the potential retirement methods available, and c) the design issues that will be present from the consideration of each retirement method. c) De Weck et al. ( 2012) talk about the "ilities" like desired properties of the system that are not the primarily system functional requirements, but the "ilities" should be considered due to their direct impact in those primarily functional requirements. The authors affirm that more recently the number of "ilities" has considerably increased because of the growing complexity of systems.

Thus, it can be concluded that non-functional requirements are as important as functional requirements, and that the quantity of non-functional requirements is directly related to system complexity.

Current industrial practices to elicit stakeholder needs

Authors like [START_REF] Hickey | Elicitation technique selection: how do experts do it[END_REF]Davis (2003) Faisandier (2012), [START_REF] Blanchard | Systems Engineering and analysis[END_REF] and SEBoK (2017) converge in saying that current industrial practices to elicit stakeholder needs are techniques or methods like structured brainstorms workshops, interviews, questionnaires, simulation, models, prototypes, and quality function deployment among others. Each method or technique has advantages and disadvantages. For example, brainstorming has the advantage of generating an enormous number of ideas; but many of them are not "quality" ideas since they are not screened, tested or evaluated; or brainwriting, that produces even more ideas that brainstorming, but that not allow verbal interaction among participants [START_REF] Brahm | Advantages and disadvantages of group decision-making approaches[END_REF]. Table 1 compares the advantages and disadvantages between interviews and questionnaires [START_REF] Akbayrak | A comparison of two data collecting methods: interviews and questionnaires[END_REF]; here, it is interesting to observe that, if these techniques are conducted simultaneously in a wise way, they would complement each other resulting in obtaining all the possible advantages.

TAXONOMY AND QUESTIONNAIRE

This section presents a taxonomy of requirements and a questionnaire whose objective is to guide the analysis and design team in identifying non-functional requirements.

Taxonomy of requirements

The taxonomy we propose results from a compilation of several complementary contributions found in literature.

Primarily based on the requirements classification proposed by [START_REF] Faisandier | Engineering and Architecting Multidisciplinary Systems[END_REF], considered here as the most complete one, it also integrates the propositions of [START_REF] Grispos | Are you ready? Towards the engineering of forensic-ready systems[END_REF], [START_REF] Ryan | Design for system retirement[END_REF][START_REF] De Weck | Investigating relationships and semantic sets amongst system lifecycle properties (Ilities)[END_REF]. The taxonomy includes both functional (expected services) and non-functional (all others) requirements (Fig. 1). The proposed requirement taxonomy should be read from the left to the right side; it shows seven main categories: six of requirements (number 1: functional requirements; numbers 2, 3, 4, 6 and 7: non-functional requirements) and one of constraints (number 5). When available, there are shown subcategories and sub-subcategories of requirements and constraints.

Questionnaire

Once the taxonomy was elaborated, each requirement definition statement was transformed into question(s); in this way, the different types of requirements are considered when stakeholder need elicitation is conducted. For example, the definition of functional requirements is "main operational activities or the highest-level of functions that the system of interest has to achieve", then, the derived question is "what are the main operational activities or the highest-level functions that the system of interest has to achieve?" Here below is presented the questionnaire, directly related to the taxonomy (Table 2). 5.4 What are the constraints concerning to the transfer for use? 5.5 What are the constraints concerning the disposal actions when the system cannot be recovered by any means? 5.5.1 Does the system has no useful parts or hazardous materials? Should the system be destroyed, disposed as waste or maybe incinerated? 5.5.2 Does the system can-not be recovered but neither destroyed? Is storage it the best solution? What documentation /information associated with the system as historical records, and the compliance with archival regulations must be kept? How long the system and its documents must be kept? 5.6 Is there a constraint of cost and delivery of the product? For example a performance of effectiveness requirement could be decreased to offer a lower cost.

5.7 What are the constraints resulting from the manufacturing actions: reuse of tools/of complete production line, gripping, test outlet, etc.?

5.8 What are the legislations, regulation applicable to the system? 5.9 What are the standard references applicable to the system? 5.10.1 What are the possibilities to use the system on its retirement stage? Is possible that the system may be reused in another life cycle: 1) as a complete system: in its original role, or in a diminish role; 2) as separate system elements, in other words, the complete system can-not be reused as a whole, but are one or more of its elements useful? 5.10.2 Is it possible that at the end of system life it could be renovated, renewed or reconditioned? Is additional work required for continuing operating the system in its original role? 5.10.3 Would the system need significant work to be able to operate in its original role? 5.10.4 Is it possible to recover saw materials from the system in order to recycle and use it in a different form, or sold as scrap? 5.11 What are another quality constraints to take into consideration?

6. Forensic Requirements 6.1 What may help the system to detect a security incident? 6.2 What data helps to discover why and how a security incident occurred? 6.2.1 What is the aptitude of the system to prevent a denial of access to a resource or information to establish the cause of an incident? 6.2.2 What forensic data is acquired during investigations? How and what logging is done? How is system examined? 6.2.3 How long forensic data must be kept? 6.2.4 What forensic data must be prevented to be tampered? 6.2.5 What forensic data is going to be analyzed in order to know the cause of the incident?

6.3 What requirements may help to avoid and prevent security incidents? 6.4 What requirements may help the system to recover by itself when a security incident has occurred?

7. Validation Requirements 7. What are the justification activities that provide elements or arguments to select the most effective solution among candidate solutions that satisfies the set of needs, expectations and requirements of stakeholders? Describe. What is the validation strategy? What are the necessary documents for validation purpose? List them. Which are the activities or procedure to validate that the system satisfies the set of needs, expectations and requirements? Ex: tests. Which are the metrics and values to accept the system?

This questionnaire was applied in three case studies to help analysis and design teams to identify non-functional requirements. These case studies are described in the following section. Based in the research work of [START_REF] Brahm | Advantages and disadvantages of group decision-making approaches[END_REF], [START_REF] Akbayrak | A comparison of two data collecting methods: interviews and questionnaires[END_REF] and [START_REF] Bouchereau | Methods and techniques to help quality function deployment (QFD)[END_REF], we propose to apply this questionnaire in the following environment: a) in a collaborative session, preferably in stakeholder's facilities, with the possibility of being virtual if some stakeholders can-not attend the session, with the availability of chat, video and phone; b) with a facilitator who leads the session. During the development of the session, the facilitator reads the question, every stakeholder express what they want to say -orally or written if they prefer to keep anonymity-, and as needed, the facilitator adds more questions -like developing an interview-in order to clarify the point. This way, the facilitator mix both techniques -questionnaire with interview-to profit the advantages of both of them.

CASE STUDIES

The case studies were led in the Instituto Tecnológico de Toluca (ITT) in student projects. Students had to design three different systems and they used the questionnaire to find the non-functional requirements. The goal for us was to evaluate the simplicity of use of the questionnaire, and the gain of performance obtained using it. Case studies are introduced here below.

Design of an information system to monitor stoppages in production lines

Industry "X" (the company name is not mentioned for confidential reasons) is implanted in six countries in Latin America; it manufactures several kinds of packaging like industrial and food service packaging, disposable medical supplies, and packaging for mass consumption. After conducting a diagnostic in industry "X", students from the ITT Computing Engineering Department realized that one of the reasons for economic losses was the uncontrolled stoppage in production lines. They proposed to design an information system to monitor these stoppages in order to measure, control, and improve the situation. In this case study it was recognized that the questionnaire provided support in finding stakeholder needs that later were translated into nonfunctional requirements. For example, when identifying mansystem interfaces, through question 4.5, the operator answered that the system may advise him through light and sound when the machine is stopped, but that he should be able to turn off this light and sound while he were serving the machine in order to avoid disturbance; he added that the visual aid should be big enough to see it without walking, and placed in an easy visible space. The operator expressed his interest in an "easy system" for him, arguing that if the system would add extra work for him -like walking-, he wouldn't use it.

Design of a web and mobile device information system for on-line shopping

On-line shopping is a practical way to save time, but it is not always easy to compare the prices of products. Students carried out a market study to find out the opinion of consumers when buying clothes on-line. Their study revealed that 88% of buyers would like to have an application to accede easier to several cloth stores and compare product prices. One example of how the questionnaire helped in this case study was when identifying the operational modes of the system; through question 4.1.1, the analysts identified the needs shown in Table 2.

Design of a wireless loader by magnetic induction through an electrical generator

It is fundamental to have electricity to do daily activities; the diverse electrical devices need an electrical feeding source and conductors to transfer the energy. Students observed that people who use bicycles as mean of transportation could generate the energy to charge their own mobile devices; nevertheless, one present problem to face is that wires make the solution non-practical and unsightly. Students proposed to design a system (electrical generator) that, assembled in the rims of a bicycle, would produce the amount of energy needed to load a mobile device in a wireless way through the application of magnetic fields. To this goal, they designed a module that reacts as a Wi-Fi network, in order to wirelessly transfer the electric power to the mobile device. In this case study, the questionnaire was valuable when identifying for example a) ergonomics and human factors, b) dependability and robustness, like avoiding damage for people; c) environmental conditions, for example the physical conditions in a rainy or sunny day.

Synthesis on the use-cases

As it can be seen, the three case studies addressed different kind of systems: a production system, a software system, and an electrical system. Using the questionnaire helped the students -who had not any experience in system design-to identify the non-functional requirements and to take them into account in their designs. Non-functional requirements are not easy to find, they are not elicited in a natural way, and the use of the questionnaire made it possible; that is the value added by the proposed taxonomy and related questionnaire. Nevertheless, during the application of the questionnaire some troubles were detected: a) some vocabulary was not familiar for the students, some questions were thus not well understood nor answered; and b) the systems were not very complex, for that reason some kinds of requirements (like some "ilities" and forensic requirements) were not identified as "needed"; one positive point is that the questions were asked, not forgotten, even if the answer of a question did not have a requirement as a result. After the experiments, an evaluation questionnaire was answered by the students and their professors in order to find opportunities for improvement. They are: a) to automatize the questionnaire with a software tool to facilitate its use; b) to give the possibility of consulting a glossary to better understand the definitions; c) in order to save time and have more ideas, every participant could answer the questionnaire by her/himself before the collaborative session is conducted; d) the facilitator of the collaborative session could be external, not an involved stakeholder, to bring impartiality.

CONCLUSIONS

In a changing and evolving environment, it is necessary to adapt the way of creating new systems for the emerging needs of the customers. The questionnaire that we propose is a simple but efficient approach to support and initiate correctly the development of complex systems. The questionnaire helps the analysis and design teams to find the requirements that are not naturally easy to identify; moreover, if ever new kinds of requirements would be discovered, they may be added to the taxonomy and the questionnaire may evolve to include very specific system needs. Nevertheless, it is important to remember that "consensus exists that one elicitation technique can-not work for all situations" [START_REF] Hickey | Elicitation technique selection: how do experts do it[END_REF].

Fig. 1

 1 Fig. 1 Proposed Requirement Taxonomy

Table 1 . A summary of advantages and disadvantages of interviews and questionnaires. (Akbayrak, 2000)

 1

Table 2 .

 2 Questionnaire What are the Operational Modes (on/off, standby, run, maintenance, etc.)? What is the system expected to do in each mode? What are the trigger events that initiate the transition from one mode to another one? 4.1.2 Describe each Operational Scenario 4.1.3 What are the Incident Modes? What the system is expected to do in each mode? What are the trigger events that initiate the transition from one mode to another one? 4.1.4 Describe each Incident Scenario 4.2 What are the physical conditions to which the system is submitted? Describe. 4.3 What are the consumed resources or produced elements by the system, what do not belong to the system? Is it possible to define the requested autonomy, expected maximum of consumption or rejections, etc.?

	1. Functional Requirements
	1. What are the main operational activities or the highest-level functions that the
	system of interest has to achieve?
	2. Effectiveness / Performance Requirements
	2. What is the expected performance or effectiveness of the system? What is the
	quality metric of effectiveness?
	3. Interface Requirements
	3.1. What are the functional interfaces between the system and the components of
	its operational context?
	3.2 What are the physical interfaces that connect the system to the components of its
	operational context?
	4. Utilization or Operational Requirements
	4.1.1 4.4 What are the requirements concerned to conditions of maintenance and logistics,
	duration of maintenance actions, management of spare parts, availability of
	maintenance equipment, qualification of the maintenance team, possibility or not for
	having specific tools, marking, identification, etc.? Consider preventive, corrective,
	and predictive maintenance.
	4.5 What are the expected man-system interfaces? What are the expected available
	commands and information? What are the disturbing elements resulting from the
	environment that could influence the operator? Describe.
	or
	unintentional external threats?

4.6

What are the requirements concern transportation? What are the requirements concern storage? What are the requirements concern handling? 4.7 What are the requirements concerning the user documentation as installation, operating and utilization of the system, preventive, corrective, and predictive maintenance procedures, training handouts, etc.? 4.8.1 What is the expected system ability to resist to natural, accidental

Table 2 Example of identified needs

 2

	Operational	On/off	Operation	Maintenance	Waiting for server
	Modes				connection
	The system is	Get fast	Maintain a fast	Engineers	Maintain a stable
	expected to	connection to	connection to	working on the	connection to
		server	server	system	server


Diego Armando Díaz Vargas

Rui Xue
email: xuerui@bjut.edu.cn

Claude Baron
email: claude.baron@laas.fr

Philippe Esteban
email: philippe.esteban@laas.fr

Rob Vingerhoeds
email: rob.vingerhoeds@isae-supaero.fr

Y A Citlalih
email: citlaligh@yahoo.com

Gutierrez Estrada

Chao Liu
email: liuchao@bjut.edu.cn

"The rise of connected systems in industry and services" IMPLEMENTING SCRUM TO DEVELOP A CONNECTED ROBOT

Keywords: systems engineering, connected systems, agile management, integration, mobile robot, SCRUM

Agile methods are receiving a growing interest from industry and these approaches are nowadays well accepted and deployed in software engineering. However, some issues remain to introduce agility in systems engineering. The objective of this paper is to show an agile management implementation in an educational project consisting in developing a connected mobile robot, and to evaluate the issues and benefits of adopting an agile approach. Among the most famous agile management methods, SCRUM has been chosen to lead this experiment. This paper first presents the project and how students traditionally manage it, then it describes how Scrum could be used instead. It evaluates the difficulties and interests to introduce agility in this project, and concludes on the ability of Scrum to design, test and progressively integrate the system, thus providing an operational prototype more quickly.

INTRODUCTION

Every year, the Institut National des Sciences Appliquées de Toulouse (INSA Toulouse, Université de Toulouse, France) proposes a project to master students with an objective to design and realize a remotely controlled LEGO Mindstorms robot. The six to eight students project team is supervised by a professor, in charge of explaining the robot mission and helping with the management of the three-months project. The students' assignments are to define the necessary resources and contributing systems, and to organize their work and their team in order to be able to deliver the robot on time.

The project includes the development of the robot as well as the writing of a complete report, in which technical and organizational aspects have to be detailed. Students traditionally follow the V-cycle model to develop the system. The project is divided into six stages: initiation, preliminary development, principal development, robot realization, test and close. Although the V-cycle is a widely used reference in the industry, with the emergence of agile approaches, many project managers have paid attention to agile management of projects, essentially in software engineering projects. Therefore, students must be trained to agile management before joining the industry.

This article aims at deploying, testing and evaluating the issues and benefits of an agile approach on this project, in order to determine if it could be a candidate to train stu-dents to a basic practice of agile management. To this purpose, this paper considers and compares two options to implement agility.

The paper is organized as follows. Section 2 presents the way students are currently managing their project. Section 3 outlines the principles of the agile approach. Section 4 explains how the students could handle the project in an agile way. Section 5 concludes on the feasibility and interest of training students to an agile management on this project.

DEVELOPMENT OF A CONNECTED MOBILE ROBOT

The objective of the project is to deliver an autonomous remotely supervised wheeled robot. It includes the design and construction of the robot using LEGO building blocks.

The robot can either be remotely operated or move autonomously on a delimited area. This area contains two distinct zones: a 'rest zone' where the robot is initially located, a 'camp' where the robot has several tasks to accomplish.

The mission of the robot is decomposed into three phases.

It first has to reach the camp by autonomously following a line traced on the ground and to signal the operator that it arrived (send a 'bip'). There, an operator remotely takes the control of the robot to realize the tasks assigned to the robot. These tasks consist in dropping several wooden tokens that are embedded in a storage module in the robot, to different predefined zones. During the remotely controlled part of the mission the operator can visualize the '18 -June 27-29, 2018 -Toulouse, France. robot environment thanks to a camera in order to avoid the different traps on the area (crevasses, low light areas, low Wi-Fi/Bluetooth areas) to drive the robot following the best route. Once the job accomplished, the robot returns to the rest zone.

MOSIM

From a given set of robot requirements, students have to define a logical and physical architecture for the robot, to construct it and to test it against its specifications. They first have to organize, divide and plan the project before dealing with more technical aspects (system analysis, conception, integration, tests, etc.). The project team has three months to lead the project.

The project team defines six stages to structure the project, with 7 milestones (named M1 to 7 in Figure 1). To lead the project, students use traditional methods, based on a predefined schedule, with cost constraints and quality objectives. They completely plan everything from the beginning, however wisely including some margins. The robot requirements are initially given to the students, as well as some physical constraints, such as the size and shape of tokens for instance. During the development stages, changes are not expected, or even allowed. This kind of management method is adapted to a V-model development cycle.

AGILE MANAGEMENT OF PROJECTS

Compared with the traditional management method used by the students, the agile management method attracts a lot of attention in industry because of several assets: flexibility, transparency, increased customer satisfaction, close communication between developers, etc. This section first compares traditional and agile management, then outlines the main advantages of agile management, to end with a brief introduction to the three mostly used agile methods.

Traditional management vs Agile management

The traditional management was characterized by [START_REF] Chin | Agile project management: how to succeed in the face of changing project requirements[END_REF], [START_REF] Fowler | The new methodology[END_REF] and [START_REF] Highsmith | Agile project management: creating innovative products[END_REF] as a methodology whose emphasis is on detailed planning and resistance to change. Schwaber (2007) corroborates that about 50 percent of the time is spent on requirements, architecture and specification, and that all this is done before even building any functionality when the project management team used traditional practices. Agile management is described as an approach that aims for flexibility, simplicity, iterating in short periods of time, and incrementally adding value [START_REF] Boehm | Get ready for agile methods, with care[END_REF], [START_REF] Chin | Agile project management: how to succeed in the face of changing project requirements[END_REF], [START_REF] Cockburn | Learning from agile software development-part one[END_REF], [START_REF] Cohn | Introducing an agile process to an organization [software development[END_REF], (Highsmith,200), [START_REF] Misra | Identifying some critical changes required in adopting agile practices in traditional software development projects[END_REF]. A comparison conducted by [START_REF] Shenhar | Reinventing project management: the diamond approach to successful growth and innovation[END_REF] highlights the main differences between the traditional and agile management method. Hoda et al. ( 2010) also compare them with a software development focus, and highlight the main differences.

Advantages of agile management

Agile management now is widely spread and especially applied in software development. Its use allows companies to quickly react to project changes and to adjust their processes and organizations. The use of agile management can also help companies to improve their success rate [START_REF] Augustine | Agile project management: steering from the edges[END_REF]) [START_REF] Serrador | Does Agile work?-A quantitative analysis of agile project success[END_REF]. The case study that has been carried out in the research of [START_REF] Serrador | Does Agile work?-A quantitative analysis of agile project success[END_REF] has demonstrated that the use of agile management method can help the companies to end projects on time, on budget, with a high customer satisfaction. Furthermore, agile project management can solve the problems induced by a change of requirements [START_REF] Azanha | Agile project management with Scrum: A case study of a Brazilian pharmaceutical company IT project[END_REF]. Azanha et al. also states that agile management practices can help companies in getting value for them and their customers by the benefits obtained with the agile approach usage, applied to systems development. Nowadays, project leaders and teams find themselves in an environment disrupted by exponential advances in technology and demands from customers for more immediate delivery of value, agile techniques and approaches effectively manage disruptive technologies (PMI, 2017). Comparisons between agile management and traditional management in literature mainly focus on the software development context. This paper analyzes the advantages of agile management in the context of a mobile connected robot, where software is embedded with physical components.

MOSIM'18 -June 27-29, 2018 -Toulouse, France.

Introduction to the three main agile management methods

Different agile methodologies are currently practiced in the industry. This subsection briefly introduces the most widely used. Among them SCRUM has been chosen for this project; it will be presented with more details.

XP

XP is an agile software development methodology created by Kent Beck and first presented in 1999, in a book titled Extreme Programming Explained: Embrace Change. According to the author, "the goal of eXtreme Programming is outstanding software development at lower cost, with fewer defects, higher productivity, and much higher return on investment" [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF]. XP does not rely on planning, analyzing and designing for the far future. Instead, it allows these activities to be made throughout the whole development, in short cycles [START_REF] Beck | Embracing change with extreme programming[END_REF]. [START_REF] Robillard | Yoopeedoo (UPEDU): a process for teaching software process[END_REF]. Many companies claimed that they have applied agile management on their projects. However, Schwaber et Sutherland suggests only 30% of scrum-adopting companies will become "excellent development organizations". Change experts like Harvard Professor John Kotter [START_REF] Kotter | Leading change: why transformation efforts fail[END_REF] regularly say 70% of major change efforts fail. Some of agile management method implementation in the companies only remain some aspects of agile management, such as its iteration or collaboration.

UPEDU

Scrum

Scrum was first proposed by Jeff Sutherland and Ken Schwaber in 1993 [START_REF] Cervone | Understanding agile project management methods using Scrum[END_REF], [START_REF] Misra | Identifying some critical changes required in adopting agile practices in traditional software development projects[END_REF]. It was originally designed for software development. Now the application of this method is not restricted to software development; it also can be applied to a large variety of domains, such as manufacturing, marketing, advertising agencies, architectural projects and banks [START_REF] Cardozo | SCRUM and Productivity in Software Projects: A Systematic Literature Review[END_REF]. Among the three main agile management methods, Scrum is widely deployed in industry. In addition, Scrum is quite simple to train students without asking them to develop an advanced expert level beforehand. We thus chose Scrum to evaluate the interests of implementing agility into our educational project.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known [START_REF] Schwaber | The definitive guide to scrum: the rules of the game[END_REF]. Scrum is therefore defined as a framework which people can address complex adap-tive problems, while productively and creatively delivering products of the highest possible value. This framework consists of scrum teams and their associated roles, events, artifacts and values, each component serves a specific purpose and is essential to Scrum's success and usage. Below a brief description of the different Scrum aspects is given (adapted from [START_REF] Schwaber | The definitive guide to scrum: the rules of the game[END_REF]:

Scrum Values

The Scrum values are followed by everyone in the project.

It enumerates five values:

1) V 1 -Courage, Scrum Team members have courage to do the right thing and work on tough problems, 2) V 2 -Focus, everyone focuses on the work of the Sprint and the goals of the scrum team, 3) V 3 -Commitment, people personally commit to achieving the goals of the Scrum Team, 4) V 4 -Respect, Scrum Team members respect each other to be capable, independent people, and 5) V 5 -Openness, the Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

Scrum Events

Scrum Events are specifically designed to enable critical transparency and inspection. Each event is a formal opportunity to inspect and adapt something. All events are time-boxed events and they may ensure an appropriate amount of time without allowing waste in the process. Scrum enumerates five events:

1) Sprint -a time-box of one month or less, during which a usable and potentially releasable product increment is created; an increment is the sum of all the items completed during a sprint and the value of the increments of all previous Sprints. The Sprint is the heart of Scrum and a new Sprint starts immediately after the conclusion of the previous Sprint. 2) Sprint Planning -a time-box to a maximum of eight hours for a one-month Sprint. Sprint planning plans the work to be perform in each Sprint. This plan is created and maintained by the collaborative work of all members of the project. Sprint planning also defines the sprint goal, an objective set for the Sprint, that can be met through the implementation of the Product Backlog. 3) Daily Scrum -a 15-minute time-boxed event, held every day of the Sprint. Daily Scrum is use to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. 4) Sprint Review -the inspection of the increment.

During this inspection stakeholders review the MOSIM'18 -June 27-29, 2018 -Toulouse, France.

results of a Sprint. A Sprint Review is held at the end of the Sprint and adapts the Product Backlog if needed. 5) Sprint Retrospective -an opportunity for the team to review itself and create a plan for improvements to be done during the next sprint. Sprint Retrospective occurs after the Sprint Review and prior the next Sprint Planning.

The Scrum Team

Scrum Teams have as a characteristic "self-organizing and cross-functional". Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others. Furthermore, the Scrum Team delivers products iteratively and incrementally, maximizing opportunities for feedback. A Scrum Team comprises three entities:

1) a Product Owner: one person only and its decisions have to lead the entire team and the organization, 2) a Development Team: professionals who do the work of delivering a potentially releasable increment of product at the end of each sprint, and 3) a Scrum Master: it is responsible for promoting and supporting scrum framework, he does this by helping everyone understand practices, rules, values and scrum theory.

Scrum Artifacts

Scrum Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation; they are designed to maximize transparency of key information. Product Backlog is considered as an ordered list of everything that is known to be needed in the product; the Product Owner is responsible for the Product Backlog. Sprint Backlog is the set of Product Backlog items selected for the Sprint, a plan for delivering the product increment and realizing the Sprint Goal; it makes the work that the Development Team identifies as necessary to meet the sprint goal visible. The Increment indicates the sum of all the Product Backlog items finalized during a Sprint, as well as the ones finished during all previous sprints. Product Backlog, Sprint Backlog and Increment are considered as artifacts.

Figure 2 shows the complete Scrum Framework and how each entity is distributed. The framework begins with the Product Backlog; the Product Owner defines all the features that the Development Team has to do and then to prioritize. The next step is the Scrum Planning; here the Product Owner and the Development Team plan which features of the Product Backlog have to be done and the time of each Sprint, which results in the Sprint Backlog.

The Development Team has to do each Sprint defined in the Sprint Backlog. They have to hold daily meetings to organize the work that has to be done. Sprint Review allows the Development Team to solve the problems that occurred during the sprint development.

Figure 2: Global Scrum Framework (scrum.org, 2017)

USING AGILITY IN THE ROBOT PROJECT

Our proposal is to introduce agility in three project phases: principal development, robot realization and test phases (see Figure 1). This section considers and discusses several options to implement Scrum in these phases.

Implementing Scrum in the project

The robot mission is to move in a predefined environment, autonomously or remotely operated, as mentioned in Section 2. More specifically the robot shall achieve its mission following three successive phases:

-Phase 1: The robot shall move autonomously from the 'rest zone' to the 'camp' and send an audible signal once it arrives at the 'camp'. -Phase 2: The robot shall drop tokens in predefined zones under the operator directions, avoiding traps on the route (one crevasse, two low light areas and three low Wi-Fi/Bluetooth areas). -Phase 3: The robot shall join the 'rest zone' under the operator commands from an operating terminal.

These three phases can be considered as a Product Backlog and can be used to initiate the Sprint Planning. Before starting the Sprint Planning, students should decide who is going to be the Product Owner, the Scrum Master and who will contribute to the Development Team; the goal of this role definition is to focus on the scrum framework recommendations. Students can define the global architecture of the robot using the given requirements, that allows them to identify the different interactions between stakeholders and the robot. The robot can be decomposed into three subsystems as shown in Figure 3: the robot structure and motion subsystem, the vision subsystem and the Human Machine Interface subsystem. The robot structure and motion subsystem corresponds to the physical architecture of the robot with the motion subsystem; it has to answer all requirements of the specifications. The vision subsystem will allow an optimal view to the robot to accomplish its mission and the human machine interface subsystem will allow to remotely command the robot.

Then two different options can be considered for implementing the Scrum framework:

1. to define the sprints on the basis of the decomposition of the architecture into subsystems (Figure 3). Each sprint will address the development of one subsystem considered independently from the others, a supplementary sprint will address the integration of subsystems. 2. to define sprints on the basis of the phases of the robot mission. This means analyzing which parts of subsystems are invoked at each phase of the mission and define sprints aiming at incrementally developing these specific parts. Figure 4 shows the decomposition of each subsystem of the robot into parts. S1 and S2 are subsystems of the robot structure and motion subsystems, V1, V2 and V3 of the vision subsystem, HMI1 and HMI3 of the human machine interface subsystem. On the figure, we can see that the option taken here is to develop S1, V1 and HMI1 at one sprint, S2 and V2 at another sprint, and V3 and HMI3 in another sprint.

Figure 4: Distribution of the robot subsystems These two options are presented here below.

Option 1

To define the sprints, the Product Owner has to prioritize the features inside the Product Backlog then plan each sprint with the Development Team. According to this project, we can distribute the Product Backlog using as a reference the global architecture defined in Figure 3, each sub-system is considered as a feature of the Product Backlog and shown in Figure 5. We thus propose four sprints, one sprint for each subsystem and a supplementary sprint for the assembly.

-Sprint 1: the first artifact is the architecture and motion system of the robot; it is the result of the first sprint. -Sprint 3: the human machine interface is the third increment of this sprint. The result of each sprint is considered as an increment, which means that once the first sprint is completed, the detail of the next phase (second sprint) is worked out, and so on. Each sprint has to follow a daily sprint meeting to know the status of the activities defined in each sprint, followed by the sprint review. If everything is OK, the development team can do the increment, otherwise the development team has to hold the sprint retrospective to correct or redefine the sprint. The proposal has to follow the framework described in Figure 2.

The focus point of this proposal is the architecture of the robot. The first three sprints follow a list of activities that allows to deliver and test a specific and independent part of the robot, each increment of these sprints are assembled in a fourth sprint to have a fully operational robot.

Option 2

This option proposes to identify which subsystem is invoked at each phase of the robot mission. To define the sprints, the Product Owner can consider the decomposition of the robot subsystems (Figure 4) as the Product Backlog then starts the sprint planning. Product Owner also has to prioritize the features inside the Product Backlog, then plans the sprints with the Development Team.

Once the sprints were defined, their development has to follow the framework described in Figure 2, in that case the increment is considered as the result of the integration of each subsystem to accomplish each phase of the global mission, sprints have to follow a daily sprint meeting and the sprint review as stablish in the scrum framework. To illustrate how sprints can be defined in this option, we presented the first sprint as follows:

-Sprint 1: the first artifact of this sprint is the integration of three subsystems to accomplish Phase 1. It needs the subsystem S1 (from the robot Structure motion and subsystem), V1 (from the Vision subsystem), and HMI1 (from the human machine interface subsystem).

Figure 10: First sprint, the mobile module and HMI

Figure 10 shows the first sprint of this proposal. The activities were defined considering the subsystems needed and the integration of them is considered as the result of the first sprint (increment). The definition of the other two sprints should follow the same analysis.

This proposal stablishes a different way from the first one.

After the roles definition, Product Owner identifies which subsystems were involved to complete each phase of the global mission then defines each sprint. It allows to deliver artifacts that contains hardware and software at the same time.

Discussion

Section 4.1 shows two different conceptual ways to implement the Scrum Framework as an alternative to the traditional management methods, the goal of this implementation is to develop a mobile connected robot in an agile way. The implementation was proposed following three phases that the robot has to follow to accomplish a global mission. In fact, this work is focused in order to evaluate if the development of the project robot is a good case study to implement the scrum framework, considering that this project not only includes software development but also hardware integration.

From the implementation of agile management on this educational project, we can find that developing the robot with Scrum could help students to deliver functional modules in each increment and reduce time for testing as presented. For example, they delivered functional parts of the robot including hardware and software at the same time in '18 -June 27-29, 2018 -Toulouse, France. each sprint. The results of this proposal will be evaluated at the end of the school year.

MOSIM

This work also opens an additional discussion point relative to this investigation. The architecture and requirements were well defined before, but what if during the development that changes? As we know, requirements can be changed during the development; so, these changes may be discussed in the sprint review or in the sprint retrospective, but we do not really know if that will have a strong impact in the architecture. This point shall be evaluated next year, when agility will be implemented in new student projects.

Some difficulties could exist when trying to implement agile management methods on the mechanical development projects. For example, during the project, the project individual had more and more stress because of the selfmanagement and self-organization rather than having direct orders from their superiors. From the management's view this creates uncertainty of project. entire team is actually held accountable for the success or failure of a project even when the product owner is to be held responsible. It is not easy to divide the project into sprints according to the functions of product, this issue will be analyzed when students use the proposals stablished next year. Differences between the traditional management of the project and the implementation of an agile approach is another criterion to be considered as part of the analysis of this integration.

CONCLUSION

This article aimed at deploying, testing and evaluating the issues and benefits of an agile approach on a student project, in order to determine if this project could be a candidate to train students to a basic practice of agile management.

To this purpose, this paper considered and compared two options to implement agility. In the first option, four sprints were defined with a specific duration and related activities; at the end of each sprint, students can deliver a functional part of the robot and test it. In the second option, the sprint definition relied on the subsystems involved to achieve each phase of the global mission of the robot; it allows delivering software and hardware modules in parallel. During the sprint development, in both cases, close communication should be effective in order to cover all the requirements defined in the robot specifications. Specific roles should be considered to manage the evolution of the robot development; these roles allow the distribution of responsibilities during the development.

The paper concludes that implementing an agile method such as Scrum in this project during the system development could be interesting for students to improve cooperation among students, and quickly and efficiently develop the connected mobile robot, thus improving project performance. It also concludes that implementing Scrum in this project could allow to train students to basics of agile management.

Figure 1 :

 1 Figure 1: The six stages of the project Initiation: organization of the project group and definition of the responsibilities of each team member. Preliminary development: definition of requirements, of alternatives for the robot architecture and of test cases. Principal development: definition of the specifications and of the architectures of sub-systems; integration, validation and verification. Robot realization: development of a robot prototype with LEGO bricks, improvement of the robot performance. Test: students define test cases to verify the robot behavior and performance. Close: students have to close the project before the deadline.

Figure 3 :

 3 Figure 3: Global architecture of the robot

Figure 5 :

 5 Figure 5: Product Backlog of the robot project

Figure 6 :

 6 Figure 6: First sprint, the architecture and motion subsystem of the robot -Sprint 2: the second artifact is the vision subsystem

Figure 8 :

 8 Figure 8: Third sprint, the human machine interface -Sprint 4: this is the last sprint; the entire robot is the result of this sprint.

Figure 9 :

 9 Figure 9: Fourth sprint, entire robot

Available at: https://en.wikipedia.org/wiki/UPEDU [Accessed 19 December 2017]. .


Yannick Pencolé
email: ypencole@laas.fr

Audine Subias
email: subias@laas.fr

Timed pattern diagnosis in timed workflows: a model checking approach

Keywords: Diagnosis, Time Petri Net, Timed Pattern, Model checking

In this article we introduce the problem of timed pattern diagnosis in timed system and propose a method to solve a sub-class of theses problems: the problem of timed pattern diagnosis of workflows. It consists in searching for all the possible evolutions of the workflow that are consistent with a timed sequence of observations and determining whether these evolutions match a pattern of timed events instead of a single fault event. The formal characterization of the diagnosis problem is based on the notion of pattern matching. Defined as a reachability problem, the diagnosis problem is then solved by model checking.

INTRODUCTION

The problem of fault diagnosis in DESs was introduced in [START_REF] Sampath | Diagnosability of discrete-event systems[END_REF]. Later, extensions of the problem handling time have been proposed using timed automata [START_REF] Tripakis | Fault diagnosis for timed automata[END_REF]) and more recently Petri nets with several interpretations of time and methods, for instance: [START_REF] Chatain | Time supervision of concurrent systems using symbolic unfoldings of time petri nets[END_REF], [START_REF] Jiroveanu | A distributed approach for fault detection and diagnosis based on time petri nets[END_REF], Basile et al. (2007), [START_REF] Bonhomme | Fault diagnosis of p-time labeled petri net systems[END_REF], [START_REF] Boel | The On-Line Diagnosis of Time Petri Nets[END_REF], [START_REF] Basile | State estimation and fault diagnosis of labeled time petri net systems with unobservable transitions[END_REF], [START_REF] Liu | An efficient approach for diagnosability and diagnosis of DES based on labeled Petri nets -untimed and timed contexts[END_REF], [START_REF] Wang | Diagnosis of time petri nets using fault diagnosis graph[END_REF]. These contributions describe some methods for the same problem that is the diagnosis of single faults in a timed system. In this article we propose to extend the diagnosis problem to more complex behaviors than single events called timed patterns and to apply it to timed workflows. Timed patterns extend with time the classical notion of pattern [START_REF] Jéron | Supervision patterns in discrete event systems diagnosis[END_REF]; [START_REF] Gougam | Diagnosability analysis of patterns on bounded labeled prioritized Petri nets[END_REF]). Beyond faulty behaviors, classical patterns can represent any untimed normal behavior of interest or any behavior associated with a system specification as in [START_REF] Jiang | Failure diagnosis of discreteevent systems with linear-time temporal logic specifications[END_REF]. In [START_REF] Bozzano | Formal design of asynchronous fault detection and identification components using temporal epistemic logic[END_REF], such patterns are called diagnosis conditions and are represented with LTL (Linear Time Logic) properties with past operators.

As classical patterns, the proposed timed pattern models more complex behaviors than a single event (sequences, concurrent events,...) but it also add the possibility to model a time interval between the occurrence of two events in the patterns. Timed pattern can then naturally model unexpected/unacceptable/faulty time delays between two unobservable events. In this article we firstly propose to formally define the general problem of timed pattern diagnosis in timed system. We then propose a method based on model-checking techniques that solves a subclass of this new problem that is the timed pattern diagnosis in timed workflows. Given the observable part of the run of a workflow, the diagnosis problem consists in determining whether the considered timed pattern has occurred or not during the run of the workflow. The proposed method first converts the problem into a reachability problem and then use model checking tool to solve it. Section 2 formally defines the general problem. The proposed method is presented in Section 3. An illustrative example about a service workflow is described in Section 4.

GENERAL PROBLEM STATEMENT

The objective of the approach is to diagnose the occurrence of a timed behavior (i.e a timed pattern) in a timed system. It supposes the implementation of a diagnosis function that takes as input a sequence of observations and returns one of the following three results:

(1) The pattern's behavior has certainly occurred.

(2) The pattern's behavior is certainly absent.

(3) The pattern's behavior may have occurred, ambiguity.

This section defines the different parts of the problem that is: how to model timed systems/timed patterns, how to formally define the occurrence of a timed pattern, what is finally the diagnoser function.

Preliminaries

This paper deals with timed sequences. Let Σ be an alphabet that is a finite set of symbols, each symbol represents an event. A timed sequence over Σ is an element of T (Σ) = (N + × (Σ ∪ λ)) + . Suppose for instance that Σ = {a, b, c}, ρ = (a, 3), (λ, 1), (c, 1), (c, 1), (b, 2), (λ, 5) also denoted 3a1λ1c1c2b5λ is a timed sequence, ρ = 1b1b40λ is another one. Symbol λ defines a timepoint (basically 1λ2λ is the same as 3λ). The empty sequence of T (Σ) is given by 0λ.

For any timed sequence it is possible to define a canonical form δ 1 e 1 ..δ n e n δ n+1 λ, e i ∈ Σ that is obtained by removing useless time points. For instance the canonical form of ρ = 3a1λ1c1c2b5λ is 3a2c1c2b5λ. In this article and without loss of generality only canonical forms are considered. The projection of a timed sequence ρ over a sub-set Σ p of Σ (denoted P t Σp (ρ) ) is the timed sequence obtained by removing any symbols that does not belong to Σ p and by summing the durations between two symbols that are still present after the removal. Let us consider the canonical form of ρ, it corresponds to an event a that occurs at date 3 after the origin of time, an event c that occurs 2 units of time after a (so c occurs at date 5), followed by an event b, 1 unit of time later (so at date 6), and so on. Given Σ p = {a, b} then P t Σp (ρ) = 3a5b5λ. Any sub-set (canonical sub-set) of T (Σ) is a timed language over Σ. Let time(ρ) denote the sum of all durations in ρ, then time(3a4c2λ1b2b4λ) = 3 + 4 + 2 + 1 + 2 + 4 = 14. ρ is a prefix of ρ if time(ρ ) ≤ time(ρ) and there exists ρ such that ρ ρ and ρ have the same canonical form.

Matching

Like untimed discrete event system, a timed discrete event system generates a finite set of events Σ. The difference is that in the timed case, the possible time durations between the occurrence of two successive events are defined, whereas in the untimed case, the events are only connected by a precedence relationship. Of course in both cases (timed and untimed), two events may not be related i.e even the order of their occurrence is not known. An evolution of a timed discrete event system is a timed sequence on its alphabet. The set of possible evolutions of a timed system is thus a set of timed sequences, that is, a timed language. Definition 2.1. (Timed system). A timed discrete event system whose set of events is Σ, is a timed language L ⊆ T (Σ) such that if ρ ∈ L then any of its prefixes is in L.

The set of events Σ generated by the system is partitioned into two subsets: observable events Σ o and unobservable events Σ u . Two timed sequences can be linked by the notion of matching that states whether a sequence is present inside another. Definition 2.2. (sequence matching). A sequence ρ ∈ T (Σ) matches a sequence σ ∈ T (Σ), denoted ρ σ, if:

• σ = δλ and time(ρ) ≥ δ, with: δ ∈ N; or • σ = δ 0 e 0 σ 1 , such that:

δ 0 ∈ N, e 0 ∈ Σ, σ 1 ∈ T (Σ)
and there exist two timed sequences ρ 0 , ρ 1 ∈ T (Σ) and a duration δ ∈ N such that:

(1) ρ = ρ 0 δe 0 ρ 1 ;

(2) δ 0 = time(ρ 0 ) + δ;

(3) ρ 1 σ 1 .

In other words, ρ matches σ if σ is a sub-word of ρ. Figure 1 illustrates how the sequence ρ = 2b3c2a5a1c1c3λ matches the sequence σ = 7a7c0λ. The first event of σ is a and occurs at date 7. In ρ, there is also an event a that occurs at date 7 = 2 + 3 + 2. The second event of σ is c that occurs 7 time units later than a. This event is matched with the third event c of ρ that occurs 5 + 1 + 1 = 7 time units after a. Finally, σ ends instantaneously after event c while ρ lasts 3 time units more so ρ matches σ.

We define a timed pattern as a set R of timed sequences which define a behavior of interest. For example, it may be the occurrence of a single event in a given time period, the occurrence of several events that occur in any order, but whose occurrence dates have constraints or the occurrence of several events that occur in a fixed order with specific time constraints. As in the original diagnosis problem that considers unobservable fault event, we consider that the behavior of the pattern is not observable i.e no event of the pattern is observable in the system. Definition 2.3. (Timed pattern). A timed pattern over a set of events Σ R ⊆ Σ u , is a timed language R ⊆ T (Σ R ) such that if Note that the timed language of a pattern gives only the required behavior and does not take all the possible events of the system into account. For instance, the pattern an event a occurs after an event b is defined by the timed language {δ 0 bδ 1 aδ 2 λ, δ 0 , δ 1 , δ 2 ∈ N}. In this way, the pattern representation is rather in intention than in extension as the representation proposed by [START_REF] Jéron | Supervision patterns in discrete event systems diagnosis[END_REF] in the case of untimed patterns that depends on a given set of events. In addition to provide a more concise way to model the pattern, this representation reinforces the separation between the system and the diagnosis objectives. Moreover such a representation is well suited to check if a sequence ρ includes the behavior of interest. Indeed, it suffices to check if it is possible to extract from the event sequence ρ ∈ T (Σ) an ordered set of events that is a word of the language R generated by the pattern. In this case we say that the sequence ρ is R-matching. Definition 2.4. (R-matching). Let R be a timed pattern, a sequence ρ ∈ T (Σ) is R-matching if there exists a sequence ω ∈ R such that ρ ω (i.e ρ matches ω).

Timed pattern diagnosis

Finally, we propose here to extend the original fault diagnosis problem to consider more complex behaviors than simple faults: behaviors described by timed patterns. For a given behavior pattern R, the diagnosis problem is to define a Rdiagnoser function that takes as input a sequence of observations and returns one of the three symbols: {R -certain, R -absent, R -ambiguous} Definition 2.5. (R-diagnoser). Given L the timed language of the system over the event set

Σ = Σ u ∪ Σ o , an R-diagnoser is a function ∆ R : T (Σ o ) → {R -certain, R -absent, R -ambiguous} such that: • ∆ R (σ) = R -certain if for any sequence ρ ∈ L such that P t Σo (ρ) = σ, ρ is R-matching; • ∆ R (σ) = R -absent if for any sequence ρ ∈ L such that P t Σo (ρ) = σ, ρ is not R-matching; • ∆ R (σ) = R -ambiguous otherwise.
Considering a set of patterns R 1 , . . . , R n the diagnoser function is defined by:

∆ : T (Σo) → n i=1 {R i -certain, R i -absent, R i -ambiguous} such that ∆(σ) = (∆ R1 (σ), . . . , ∆ Rn (σ)).

DIAGNOSIS BY MODEL CHECKING

The proposed method defines the problem of timed pattern diagnosis as a problem of reachability and uses model checking technics to solve it. This resolution relies on the TINA toolbox (TIme Petri Net Analyzer) [START_REF] Berthomieu | The tool tina -construction of abstract state spaces for Petri nets and time Petri nets[END_REF]). Given a system and a pattern, the method proceeds as follows.

(1) The timed languages of the system and of the pattern are modeled by L-type Labeled Time Petri nets respectively denoted Θ and Ω.

(2) From the two previous nets, a new net is built (Θ Ω ) that captures the matching relation between the system and the pattern.

(3) The input observation sequence is transformed into an Ltype Labeled Time Petri net (denoted Obs). (4) The result (Θ Ω ) is then synchronised with the Petri net model of the observation sequence (Obs) to obtain the net (Θ Ω ||Obs).

(5) The model checker of TINA is used to verify the matching property between the system and the pattern according to the input observation sequence on the net (Θ Ω ||Obs). (6) The diagnosis result is thus given according to the answer of the model checker.

All the steps are detailed hereafter.

Timed languages modeling

The approach relies on the following class of Time Petri Nets (see [START_REF] Berthomieu | Bridging the gap between timed automata and bounded time Petri nets[END_REF] and [START_REF] Peterson | Petri nets[END_REF]). Definition 3.1. (LLTPNPr). An L-type Labeled Time Petri Net with Priorities (LLTPNPr for short) is a tuple N = P, T, A, , , L, Σ, I s , Q, M 0 with:

• P : a finite set of nodes called places;

• T : a finite set of nodes called transitions and P ∩ T = ∅;

• A ⊆ (P × T ) ∪ (T × P ) is the set of arcs between nodes.

• ⊂ T × T : the priority relation, not reflexive, not symetrical and transitive; (t 1 t 2 ) means that if t 1 and t 2 are both enabled then only t 1 is firable.

• : P ∪ T → L ∪ Σ ∪ {λ}: the deterministic labelling function where L (resp. Σ) is the set of place labels (resp.transition labels); For r = δ 1 t 1 δ 2 t 2 • • • ∈ (N × T ) , (r) = δ 1 (t 1 )δ 2 (t 2 ) .
. .; • I s : T → I + : the static time interval function, where I + is the non empty set of time intervals with non negative rational bounds. • Q: the set of final markings and M 0 the initial marking.

A marking M is a function from P to N which maps each place with a number of tokens. For an LLTPNPr N , the functions pre(t) = {p ∈ P : (p, t) ∈ A} and post(t) = {p ∈ P : (t, p) ∈ A} are defined. A state of N is a couple M, I , with: M a marking and I the firing interval of the transition .

Priorities ( ) aim at managing transition conflicts and modify the classical transition firing rules. Transition t is firable from state M, I after a duration δ, denoted M, I → [δt], if:

(1) M pre(t);

(2) δ ∈ I(t);

(3) ∀t = t : M pre(t ) =⇒ δ ≤ sup(I(t )); (4) ∀t ∈ T t : M pre(t ) ∨ δ / ∈ I(t ).
Intuitively, t is firable after δ time units from state M, I , if

(1) t is enabled, (2) δ belongs to the time interval associated with t and is not greater than the upper bound of any other enabled transition t , (3) at time δ, t has the highest priority among the transitions that could be fired without the defined priorities. R(N , M 0 , I 0 ) is the set of reachable states from M 0 , I 0 , with M 0 the initial marking and I 0 the restriction of the static time interval function to the enabled transitions at M 0 . As a L-type net (see [START_REF] Peterson | Petri nets[END_REF]), an LLTPNPr N generates the timed language L(N ) that is the set of timed sequences issued from the transition sequences generated by the net and leading to a final marking M ∈ Q ∩ R(N , M 0 , I 0 ). Definition 3.2. (Timed system model). A timed system of timed language L is an LLTPNPr

Θ = P Θ , T Θ , A Θ , Θ , Θ , L Θ , Σ Θ , I sΘ , Q Θ , M 0Θ such that Q Θ is the set of reachable markings and L = L(Θ).
Figure 5 presents an LLTPNPr model of a system used in the application section (see section 4). Definition 3.3. (Pattern model). A pattern of timed language R is an LLTPNPr

Ω = P Ω , T Ω , A Ω , Ω , Ω , L Ω , Σ Ω , I sΩ , Q Ω , M 0Ω such

Timed pattern diagnosis of timed workflows

The general problem of timed pattern diagnosis in timed system as defined above may lead to decidability issues (Popova-Zeugmann ( 2013)). To remain computable, we now restrict the problem to a subclass of timed systems that are timed workflows. Definition 3.4. (Timed workflow). A timed workflow Θ is a timed system where any event e ∈ Σ Θ occurs at most once in a run of the workflow. Such a timed system can be represented by an acyclic and safe Time Petri net. Also, to remain computable, a pattern Ω is considered safe and conflict-free and must describe a behavior that is not reduced to the elapsed time (i.e the sequence 0λ is not part of L(Ω) which means M 0Ω ∈ Q Ω ). Finally, to keep the causality relation described by the underlying untimed Petri net, any transition not enabled by the initial marking has a static time interval with a strictly positive bound.

A model to capture the matching relation

The diagnosis function defined in Section 2.3 is based on the matching relation between the evolutions of the system that are consistent with the input observation sequence and the pattern. To capture this relation, Θ and Ω models are composed to obtain a new Petri net model denoted Θ Ω . This the middle is composed of three events and then caracterises a set of possible time behavious. The set of accepting markings Q is only composed of one accepting marking {pW 2 5 }. This pattern occurs in a system if two events a and b effectively occur in the system within the time intervals [a1, b1] and [a2, b2] respectively following by an event c that should occur in [a3, b3] after both events a and b have occurred. Finally, last pattern W3 has the particularity to have a transition associated with an unbounded time interval [a1, +•[. The accepting marking is {pW 3 4 , pW 3 5 }. This last pattern intuitively means that after time a1, as soon as d occurs, it is followed by the occurrence of a in the interval [a2, b2] and b in the interval [a3, b3].

pW 1 1 pW 1 2 b[a1, b1] pW 2 1 pW 2 2 pW 2 3 pW 2 4 pW 2 5 a[a1, b1] b[a2, b2] c[a3, b3] pW 3 1 pW 3 2 pW 3 3 pW 3 4 pW 3 5 d[a1, +•[ a[a2, b2] b[a3, b3]
Fig. 2 Single event time pattern W1(a1, b1) and behavioural patterns W2(a1, b1, a2, b2, a3, b3) and W3(a1, a2, b2, a3, b3).

5 Time Pattern diagnosability: a model checking problem

Pattern matching

Intuitively speaking, pattern diagnosis is the problem of determining the set of patterns that have effectively occurred and that could explain a sequence of observations. Associated with this problem is the diagnosability problem. Checking whether a pattern is diagnosable over a system consists in checking whether it is always possible for a diagnostic function to assert with certainty that a run of a pattern effectively occurred during one run of the system based on the produced observations. The formal definition of the diagnosis and the diagnosability problem then depend on the notion of pattern occurrence that is defined below.

A pattern W has occurred in a run r of the system if it is possible to extract from the timed event sequence r = `(r) 2 L (Q ) a timed sequence that is a word of the language L (W ) generated by the pattern, in this case we say that the sequence r matches the pattern W and is denoted r c W (we also say for convenience that the run r matches the pattern W if `(r) c W ).

Q Ω1 = {{p Ω 1 2 }}, Q Ω2 = {{p Ω 2
5 }} and Q Ω3 = {{p Ω 3 4 , p Ω 3 5 }}. model represents the synchronized evolutions of the system and the pattern but also the evolutions of the system alone as a pattern evolution corresponds potentially (in case of matching) to a sub-word of the system. The combination of both nets is obtained by performing the union of the system places and the pattern places. The transitions of the system that do not share any event with the pattern are kept with their initial time intervals. The other ones must be synchronized with the pattern's transitions. As in Time Petri nets compositionnality is kept only when synchronizations involve transitions with an interval [0, +∞[ [START_REF] Berthomieu | Bridging the gap between timed automata and bounded time Petri nets[END_REF]), we need to proceed to a time decomposition of the transitions to synchronize (see Figure 3). Transition t 1 (on the left) is labeled by a with a finite time interval [α, β]. t 1 is replaced by a sub-net (on the right) composed by a silent transition (labeled by λ not indicated on the figure) of interval [α,α] whose firing enables both a transition labeled by a (t 3 ) with the interval [0, +∞[ and a silent transition (t 2 ) of interval [βα + 1,βα + 1]. At β + 1 (i.e β times unit + one time unit) as this transition has no priority, the silent transition (t 2 ) is fired leading to an unacceptable behavior represented by the marking of a specific place unAcc. This transformation applies to transitions of the system as well as transitions of the pattern. Therefore in the system the specific place is named sys_unAcc whereas in the pattern it is pat_unAcc. Given a system Θ and a pattern Ω, each reachable marking M in Θ Ω is then the union of two markings, one is reachable in Θ, and the other one is reachable in

p 1 a[α, β] t 1 p 2 p 1 t 1 [α, α] p 2 t 2 [β -α + 1, β -α + 1] p 3 : unAcc t 3 a[0, +∞[ p 4
Ω. ∀ M, I ∈ R(Θ Ω , M 0ΘΩ , I 0ΘΩ ) : ∃ M 1 , I 1 ∈ R(Θ, M 0Θ , I 0Θ ), ∃ M 2 , I 2 ∈ R(Ω, M 0 Ω , I 0 Ω ) : M = M 1 ∪ M 2 . Moreover L(Θ Ω ) = {ρ ∈ L(Θ) : ∃ω ∈ L(Ω) : ρ ω}.
Finally Figure 4 illustrates the complete combination in Θ Ω of a system transition labeled by b and assigned with an interval System . . .

λ[1, 1] b λ[5, 5] sys_unAcc . . . Pattern . . . λ[3, 3] λ[4, 4] patt_unAcc . . . b Figure 4. Part of Θ Ω : combination of a Θ-system transi- tion (b[1, 4]) with a Ω-pattern transition (b[3, 6]).
[1, 4] with a pattern transition labeled by b with an interval [3,6]. Two transitions labeled by b appear: the one of the right results from the synchronization of the system and the pattern transitions and the left one represents the standalone evolution of the system. Priorities (dashed lines) ensure that the synchronized transition is triggered just in case of matching.

For each possible run of the system, the net Θ Ω represents whether this run matches the pattern or not.1 Finally, to solve the diagnosis problem, this model must now be confronted with a sequence of observations.

Integration of the observation sequence

The observation sequence is first modeled by an L-Type Labeled Time Petri net denoted Obs. For instance for an observation sequence 1o 1 3o 2 , Obs has one transition t 1 labeled o 1 assigned with a static time interval [1, 1]. The output place of this transition enables a second transition t 2 labeled by o 2 with an interval [3,3]. The output place of t 2 is denoted p Obs . Afterwards, the combination system-pattern (i.e the net Θ Ω ) is synchronized [START_REF] Hack | Petri net languages[END_REF]) with the Petri model of the observation sequence (Obs) to obtain the net (Θ Ω ||Obs).

To perform the synchronization the transitions of the observation sequence net (Obs) and the transitions of the combination (Θ Ω ) are transformed so that the synchronizations involve only transitions with [0, +∞[ intervals as explained in Section 3.3. The verification of the matching property between the system and the pattern according to the input observation sequence on Θ Ω ||Obs is then performed by the model checker. Then the diagnosis function (R-diagnoser) generates its results according to the answers of the model checker as presented now.

Implementation of the R-diagnoser function by Model checking

Back to the description of the method in Section 3, the overall computational complexity of the method lies in step 5 and we propose to use an off-the-shelf model checking tool to solve this part: the TINA toolkit [START_REF] Berthomieu | The tool tina -construction of abstract state spaces for Petri nets and time Petri nets[END_REF]). TINA generates enriched labeled Kripke structures from which it is possible to check properties written in SE-LTL (State/Event Linear Temporal Logic) which extends LTL in the way presented hereafter. A formula ψ is a SE-LTL formula if it is a universally quantified formula : ψ ::= ∀ϕ such that: (1) Question ϕ CERTAIN : Are we sure that the pattern is recognized in each system's behavior that produces the observations ? If the result is false the following question is asked to the model checker: (2) Question ϕ ABSENT : Are we sure that the pattern is never recognized in each system's behavior that produces the observations ?

ϕ ::= cst | r | ¬ϕ | ϕ ∨ ϕ | ϕ ∧ ϕ | ϕ | ϕ | ♦ϕ |
More formally, each question corresponds to a SE-LTL formula. Given M a marking of Obs Θ Ω , M |Ω denotes the restriction of M to Ω i.e. the marking of the pattern's places.

(1) ϕ CERTAIN ≡ ((sys_unAcc = 0 ∧ p Obs = 1) ⇒ M |Ω ∈ Q Ω ), in others words, is it always true ( ) that if the system generates Obs (sys_unAcc = 0 ∧ p Obs = 1) then (⇒) it matches the pattern

(M |Ω ∈ Q Ω ). (2) ϕ ABSENT ≡ ((sys_unAcc = 0 ∧ p Obs = 1) ⇒ M |Ω ∈ Q Ω )
, in others words, is it always true ( ) that if the system generates Obs (sys_unAcc = 0 ∧ p Obs = 1) then (⇒) it does not match the pattern (M |Ω ∈ Q Ω ).

APPLICATION TO THE DIAGNOSIS OF A TIMED WORKFLOW OF A FOODSHOP.

The proposed method is illustrated on an example denoted as the foodshop example. This example is inspired from the Web services' systems that were studied in the European project WSDIAMOND Di Nitto et al. (2009). Figure 5 presents the workflow of a foodshop service. In this type of application, fault patterns usually represent misbehaviors not compatible with the service specification instead of physical faults on hardware. In this workflow, a foodshop first receives the order of a client (sh_recvg). Within the next 3 hours, the shop must start two activities (sh_st [1,2]) in parallel. The first activity dispatches the order into two categories: the storable products (not perishable) and the non-storable products (perishable ones). This dispatch activity ends with the event sh_end_spl. The second activity selects a warehouse. For storable products, the shop queries the warehouse to check the availability of the products (sh_req_whcheck). The warehouse then checks (wh_check) and provides a feedback (available wh_send_av, unavailable wh_send_unav). For non-storable products, the shop sends directly a request to a supplier (sh_req_suppcheck) that also provide feedbacks (sp_send_av, sp_send_unav). The shop requires that the feedbacks are given within the next 4 hours. After the reception of the feedbacks, the shop decides to implement or not the order based on the availabilities (sh_decide). If one product is missing the shop cancels the order (sh_cancel), if not the shop requests the preparation for delivery to the warehouse and the supplier (sh_req_deliv). When preparations are finished (wh_end_prep_deliv and sp_end_prep_deliv), it is finally delivered. In Figure 5 (on the left), observable events are in bold. They are events from the shop that manages the whole delivery process. To illustrate the method, we consider two patterns.

Occurrence of sp_send_unav

This pattern is the occurrence of sp_send_unav. This pattern models the fact that the supplier sends as feedback that the goods are not available. This simple pattern aims at illustrating that our method extends the classical problem where fault are modeled by single events. This pattern is composed of two places pp 0 , pp 1 and one transition. Initial marking is M 0 (pp 0 ) = 1 and M 0 (pp 1 ) = 0 and the only accepting marking M ∈ Q Ω is such that M (pp 0 ) = 0 and M (pp 1 ) = 1. Consider one run of the timed workflow and suppose that it produces the observable sequence σ 1 whose conversion to Petri net is shown in Figure 5 (on the right). To solve the problem, we first build the product between the system and the pattern that is then synchronized with the Petri net of σ 1 . On the resulting Petri net, we first query to check whether any run of the system that can produce σ 1 matches the pattern with the following query ϕ CERTAIN :

[] ((sys_unAcc = 0 /\ p9=1) => (pp1=1)) TINA's response is negative: there exists at least one run of the system that produces σ 1 and for which sp_send_unav has not happened. Then we check whether these runs do not match (i.e. contain) sp_send_unav with the formula ϕ ABSENT :

[] ((sys_unAcc = 0 /\ p9=1) => -( pp1=1)) This is a positive answer. So, the diagnosis of σ 1 is that sp_send_unav did not happen. Let us consider now the observable sequence σ 2 composed of the first five events of σ 1 followed by 8sh_decide 2sh_cancel. In this case ϕ CERTAIN is true: any run generating σ 2 contains sp_send_unav. Querying TINA with ϕ ABSENT is useless: the diagnosis is certain.

Occurrence of a sequence pattern

Consider wh_send_av[0, +∞[ → wh_end_prep_deliv [70,200]. This second pattern illustrates a misbehaviour: if the warehouse sends as a feedback that the goods are available then the preparation ends within 70 and 200 time units which is considered as an unacceptable duration (quality of services is impacted). Let us consider the following observed sequence: σ 3 = 50sh_recvg 1sh_st 1sh_end_spl 1sh_req_whcheck 1sh_req_suppcheck 3sh_ decide 2sh_req_deliv 50deliv. TINA concludes that the pattern has not happened. This is due to the fact that the delivery date is time 50 after the order request. Now if we modify σ 3 by increasing the date 50 to 80, the diagnosis becomes certain.

Only the observation of time is discriminating here.

CONCLUSIONS ET PERSPECTIVES

This work extends the original problem of the diagnosis of simple faults to the diagnosis of timed patterns in timed systems. The diagnoser function is based on the notion of matching between the system evolutions that are consistent with an input sequence of observations and the pattern. A resolution of the problem based model checking techniques is proposed to solve the problem on timed workflows. This work must be completed by a diagnosability analysis inspired from [START_REF] Gougam | Diagnosability analysis of patterns on bounded labeled prioritized Petri nets[END_REF]. We are also planning to investigate other subclasses of Time Petri nets where the problem is decidable. Basile, F., Chiacchio, P., and De Tommasi, G. (2007). Improving on-line fault diagnosis for discrete event systems using

Figure 1 .

 1 Figure 1. How ρ = 2b3c2a5a1c1c3λmatches σ = 7a7c0λ: ρ σ. ρ ∈ R then only the continuations of ρ of the form ρδλ, δ ∈ N are in R.

  Figure5presents an LLTPNPr model of a system used in the application section (see section 4). Definition 3.3. (Pattern model). A pattern of timed language R is an LLTPNPrΩ = P Ω , T Ω , A Ω , Ω , Ω , L Ω , Σ Ω , I sΩ , Q Ω , M 0Ω suchthat any final marking of the set Q Ω is a dead marking and R = L(Ω) (see definition 2.3). Definition 3.3 extends the pattern model of Gougam et al. (2017) with time. Several class of patterns and systems can be considered (see Figure 2 for some examples).

Figure 2 .

 2 Figure 2. Three patterns Ω 1 , 2 and Ω 3 withQ Ω1 = {{p Ω 1 2 }}, Q Ω2 = {{p Ω 25 }} and Q Ω3 = {{p Ω 3 4 , p Ω 3 5 }}. model represents the synchronized evolutions of the system and the pattern but also the evolutions of the system alone as a pattern evolution corresponds potentially (in case of matching) to a sub-word of the system. The combination of both nets is obtained by performing the union of the system places and the pattern places. The transitions of the system that do not share any event with the pattern are kept with their initial time intervals. The other ones must be synchronized with the pattern's transitions. As in Time Petri nets compositionnality is kept only when synchronizations involve transitions with an interval [0, +∞[[START_REF] Berthomieu | Bridging the gap between timed automata and bounded time Petri nets[END_REF]), we need to proceed to a time decomposition of the transitions to synchronize (see Figure3). Transition t 1 (on the left) is labeled by a with a finite time interval [α, β]. t 1 is replaced by a sub-net (on the right) composed by a silent transition (labeled by λ not indicated on the figure) of interval[α,α] whose firing enables both a transition labeled by a (t 3 ) with the interval [0, +∞[ and a silent transition (t 2 ) of interval [βα + 1,βα + 1]. At β + 1 (i.e β times unit + one time unit) as this transition has no priority, the silent transition (t 2 ) is fired leading to an unacceptable behavior represented by the marking of a specific place unAcc. This transformation applies to transitions of the system as well as transitions of the pattern. Therefore in the system the specific place is named sys_unAcc whereas in the pattern it is pat_unAcc.

Figure 3 .

 3 Figure 3. Transformation of a transition labeled by a with a finite interval [α, β]: on the left the transition on the right the sub-net of replacement.

  ϕUϕ r ::= e | e e e ::= p | a | c | e e with p a place symbol, a a transition symbol, r a proposition, c ∈ N, ∈ {=, <, >, ≤, ≥} and ∈ {+, -, * , /}. The operators (next), (always), ♦ (eventually) and U (until) have their usual LTL semantics. The R-diagnoser is based on two questions written in SE-LTL concerning the Petri net model Θ Ω ||Obs :

Figure 5 .

 5 Figure 5. Foodshop timed workflow and the sequence of observations σ 1 = 50sh_recvg 1sh_st 1sh_end_spl 1sh_req_whcheck 1sh_req_suppcheck 3sh_decide 2sh_req_deliv 10deliv.

This property is true because the systems that are considered here are workflows (see Definition 3.4).