INDUSTRIAL PRODUCTION LINE MODELING AND REASONING BY PETRI NETS ∗

CNMAI2014-0021 Petri Nets are a widely used formalism to execute and analyze concurrent procedures. It takes advantage of an intrinsic support to parallelism and concurrence as well as of the possibility of intuitive graphical interpretation. It can be used for modeling all the behavior of procedures and tracking resources flow. Petri-PDL is a logic formalism capable of making inferences on Petri Nets even in its concurrent dealings. Besides other works evolving reasoning in concurrent systems or those using Petri Nets, Petri-PDL is a decidable, sound and complete formalism that takes advantage of Petri Nets resources. The inspection method used in a VIN (vehicle identification number) validation does not meet the quality requirements demanded by the market. In some cases reported, the inspection is performed manually, by a visual checking operator, which exposes the company to the risk of commercializing a vehicle with differences between its VIN and the vehicle documentation. Due to the emotional factor and specially fatigue, the inspection should not be performed by a person. It requires a technological tool to assist on the transcription of the validating data to the chassis in order to avoid possible problems. This work presentes a new approach based on Petri Nets using Propositional Dynamic Logics to verify whether the model of a low cost system for validating the data transcribed to a chassis is correct – and therefore efficient.


INTRODUCTION
The current criterion adopted worldwide for identifying vehicles started to take effect in Brazil in May 1988, through the National Council of Transit's (CONTRAN -BRASIL 1988) Resolution No. 691.Each identification is forged by etching and comprises the VIN (vehicle identification number), the VIS (Vehicle Identification sector), the number of the engine and the nameplate (Cecere 2010).Statistics point out a significant increase in the number of vehicles robbery and theft.Their chassis are then often tampered.This criminal practice is profitable and relatively easy to do, since the manufacturers still use obsolete methods for printing the identification data, such as puncture.Nowadays we can count on more efficient methods for vehicle identification recording, as, for example, microdots printing, which uses nanotechnology to coding the vehicle.They are not always applied, however.
The chassis recording process adopted by many Brazilian manufacturers has not been as much improved as in other countries (Cecere 2010).Many of them make use of antiquated methods of chassis recording, remarkably those guided by human visual conference.As a result, there are significant annual amounts of rework and lawsuits against the car companies.
A natural way to replace the human visual conference is to adopt a software system to perform this task.da Silva Souza et al. (2014) presents a low cost system to assist on the validation of the data transcribed by puncture to the chassis.Although this system has been submitted to a variety of tests, they are not sufficient to evaluate all possible existent scenarios.In cases like that, a formal system applied to the verification process can ensure that another system really does what it is supposed to do.
For a long time there have been intense discussions regarding the verification of software correctness.By correctness we oppose to ad hoc software development process (SDP), as they do not support all the possible decision scenarios.
The simple usage of general purpose abstractions such as UML diagrams, the latter coupled to methods (also of general purpose) that identify (or do not) steps in the SDP, do not further ensure the correct implementation of the system functionality that is required.The fact, for example, that SDP based on UML have been well accepted by the market is strongly influenced by the existence of tools for the derivation of (formally uncertified) executable codes -sometimes already in the final stage of production.
However, it is a common practice to validate through tests or simulations the code produced by the UML abstraction, for example, rather than doing this validation by means of formal analysis techniques on the abstraction level of the UML specification itself.Model checkers have been properly used for validating a behavioral specification in their abstraction level.
It is unnecessary to say that formal analysis techniques have always been used in the validation of specifications/critical systems (time-dependent, based on real-time, fault tolerant etc.), especially when they involve the preservation of human life, when errors may lead to huge financial losses or, finally, when dealing with information security.
In the case of Software Systems and the problems they solve, or the parcel of the world they help to automate, the comparison with what happens with scientific theories (STs) is perfect.In the latter, as in the former, there is no definite way to guarantee infallibility.
The validation process, as stated by Dijkstra -paraphrasing the Hypothetical-Deductive proposal for confirmation of STs -says that "the experiment (test) did not refute the hypothesis designed based on ST (system + world)".Thus, an experiment is most successful when it rejects a hypothesis constructed by the theory.That is why the wider the range of experiments (validation tests) for a system, the better.The aim is to increase the search space to be successful in the task of "finding errors".On the other hand, with what we know about probability, we can state surely that a system little tested/validated that has an infinite number of inputs or different behaviors has the same probability of being definitely correct than a very much tested/validated one.
In order to deal with system validation it is necessary to take into account its most intrinsic aspects through model checkers and theorem provers that may faithfully attest that the implemented system meets the requirements proposed for it.That is what justifies the increasing expansion of the use of various formal systems for checking systems correctness.
A widely used class of logics to reason about systems is the Dynamic Logics (Fischer & Ladner 1979) and Propositional Dynamic Logic (PDL).They are used in the most varied ways due to their being decidable and complete, among other good properties.By "decidable" it is meant that there is an effective method for determining whether a formula/argument can be satisfied or not."Complete", by its turn, means that every valid property can be verified in the system.PDL can be used for model checking (De Giacomo & Massacci 1998) and there are tools implemented for its reasoning (Schmidt 2004).
Petri Nets is present in the literature as one of the most used formalisms to deal with concurrent and parallel systems.Despite its algebraic formalism, it takes advantage of an intuitive graphical interpretation that can simplify the modeling process.
Unifying these two formalisms, Propositional Dynamic Logic for Petri Nets (Petri-PDL -Lopes, Benevides & Haeusler 2014b) is presented as a logic to reason about Petri Nets.A Petri-PDL formula is in the form s, π ϕ denoting that after some running of the Petri Net program π with initial markup s, supposing that π stops, ϕ holds on (with its necessity correspondence in [s, π]ϕ, meaning that if π stops then ϕ holds on after any of its possible runnings).Another advantage of Petri-PDL inherited from Petri Nets is that it can model the resources accumulation and consumption by the markup of the Petri Net program.
Using Petri-PDL to make inferences about a model used to implement a system that validates the data transcribed to a chassis allows the modeler to deal with resources acquisition and consumption, besides using all the other properties of Petri Nets in a decidable, sound and complete logical system.
In this paper we present a new approach based on Petri Net using Petri-PDL for modeling and verifying properties of the system presented by Souza et al. (2015).First we present the theoretical background, then a practical example on how to make inferences using Petri-PDL.

BACKGROUND
In this section we present formal method definitions and the Petri Net model used in this work.

Formal Methods
Formal methods are mathematical techniques, often supported by tools, for developing software and hardware systems.It is very important to find a suitable and comprehensive way to define and describe the underlying problem so that it becomes easier to find a solution.
Formal methods in the decade of 1970 was limited to software and hardware systems (Hoare 1972, Dijkstra 1975).But due to the complexity of the computacional systems used to manage complex systems in different industrial areas, formal methods have became mandatory to increase the reliability of these systems (Gabbar 2006).
Formal methods to ensure the reliability of critical systems become important in the decade of 1990.Rushby (1993) presented what formal methods are and how they can be applied in the development and certification of critical systems.Even NASA published a technical report on the usage of formal methods for specification and verification of software and computer systems (NASA 1998(NASA , 1997)).
Recently the logical systems, based in type theories and deductive logical systems, have been applied to model checkers and automated deduction/theorem provers, being considered as strong tools in formal methods Gabbar (2006).Amongst all the applications of logics in formal methods some of the most remarkable are the use of description logic to represent knowledge, the use o lambda calculus to construct powerful theorem provers such as Coq (Bertot & Castéran 2004) and PVS (Owre et al. 1992) and model checkers such as CTL (Alur et al. 1990).
These tools can be adjusted to comply with different logical frameworks to model and verify properties of computacional systems.This is very useful, since dealing with different models requires specific logical systems.

Petri Nets
The works presented bellow concern the Marked Petri Net Model defined by de Almeida & Haeusler (1999).In this model there are only three types of transition which define all valid Petri Nets due to its compositions.These basic Petri Nets are as in figure 1.

PROPOSITIONAL DYNAMIC LOGIC FOR PETRI NETS: PETRI-PDL
Among many logics to deal with concurrent systems (Abrahamson 1980, Benevides & Schechter 2008), Petri-PDL (Lopes, Benevides & Haeusler 2014b, Benevides et al. 2011) is an extension of Propositional Dynamic Logic (PDL -Fischer & Ladner 1979) that benefits from the intuitive graphical representation of Petri Nets and is a decidable, sound and complete formal system.It is a muti-modal logic where each modality is a program π with a markup s, says s, π .
The relation ≡ over the worlds of K is defined as and the relation R ϕ η is defined as The detailed proof is presented by Lopes, Benevides & Haeusler (2014b).

THE MODEL OF THE SYSTEM
da Silva Souza et al. (2014) presents a low cost system to assist on the validation of the data transcribed by puncture to a vehicle chassis.
The numerical sequence inserted in a chassis is composed of 17 digits, each digit making reference to a certain piece of information, such as country of manufacture, year, model, among other characteristics and purposes (BRASIL 1988).
The process of recording a chassis makes use of a machine to etching the numerical sequence.The information to be etched is inserted via keyboard or via bar code reader interfaces, allowing the inclusion of information that will be used for data manipulation or the insertion of a code to be written.
However, in the process to pick up the information, several flaws may appear, such as poorly formatted bar codes that can generate errors in reading and consequently inconsistent records, besides the possibility of a wrong typing by the operator.In this context, it is important to make a final validation of the work performed by the machine, and in case of inconsistence not to allow that the recorded chassis goes ahead along to the assembly process.
For an automated inspection it is proposed the implementation of a software that uses a low cost camera to perform data entry, providing information to the system in its sequence of tasks, going through the steps of capturing, processing and identification of the regions considered.Once this is done, then comes the optical character recognition (OCR) of the character recorded on the chassis.
The block diagram below describes the flow implemented.The image process starts focusing on the region of interest, since the other parts of the image do not contain the VIN's information.So, the processing time of the algorithms is optimized, by recognizing and working only on the numbers on the chassis.Then a contrast correction over the image is performed, since diffused lighting was not applied.
As the chassis are usually black, a correction is also applied to distribute a gray-scale on the image.The well known Canny algorithm (Hou & Koh 2003) is applied to detecting the edges of the image.In order to achieve a better location of the VIN, the Canny algorithm is applied twice, first in gray-scale and after in color scale.This region of interest is sent to the OCR for the implementation of image analysis algorithms.The process of recognition of characters contained in the digital image is performed by Tesseract Engine, which transcripts the text contained in the digital image as a plaintext.
After this, the plaintext is stored to be used to ensure that the information transcribed in the chassis is correct.If the characters transcribed match with the information required, a check mark ( √ ) is added to the image stored.Otherwise the mark × is used.
The result obtained in the OCR analysis process is recorded in the database, which can be accessed at any time.
Concerning the veracity of the information contained in the image, an authentication is included in the digital document, so that the encoding inserted in the images ensures reliability and makes future checkins easier (Rey & Dugelay 2002).
Finally, the original information and the images containing the validation tags -obtained via processing -are stored together for future audit.
We can model this process in the Petri Net as shown in Figure 6, where the numbers (labels of places) correspond to the steps described in Figure 5.
Notice that this is a high-level modelling wherewith further work will detail each step and provide other useful information to construct inferences to verify interesting properties.Using Petri-PDL, we can model this Petri Net into the formula (1), 1t 1 2 2t 1 3 3t 1 4 4t 1 5 5t 1 6 6t 1 7 7t 1 8 8t 1 9 9t 1 10 10t 1 11 5t 1 10 A where A is a proposition meaning that the process was finished.
As a usage example of Petri-PDL, we can verify if it is possible that some image may be stored before the OCR is used.
Namely, we want to verify if, from the initial stage, it is possible that the basic program 10t 1 11 runs without the basic program 5t 1 6 runs.
Notice that this proof is straightforward from the usage of the firing function definition and axiom PC.
The resolution-based calculus for Petri-PDL Lopes, Nalon, Hermann & Dowek (2014) can be used to check a formula for (un)satisfiability.

CONCLUSIONS AND FURTHER WORK
This work describes a methodology for using Petri-PDL to reason and verify system properties that validate the information casting in the chassis of vehicles.As Petri-PDL is a decidable, sound and complete formalism who inherits the advantages of Petri Nets, its use enables the usage of a "memory" where resources are accumulated and may be consumed progressively during the program execution, which well suitable for industrial modeling.This methodology can be applied to any kind of software.As the regular Petri Nets, it can deal with all aspects of concurrent systems and lets the user model the system graphically.
A next step to complete the formalization of the system built is to validate the code generated.This is also a future work, that will be done with the help of the automatic proofing and model checking.

Figure 3 .Figure 4 .
Figure 3. Examples of Sequence and Joint rules applications where black boxes represent any valid subnet of a Petri Net Figure 5. Model of System

Figure 6 .
Figure 6.Process modelled as a Petri Net