COMPUTATIONAL TOOL FOR AUTOMATIC DESCRIPTION OF TIM AND NCAP (IEEE STD. 1451) SPECIFIED IN XML AT HIGH LEVEL OF ABSTRACTION AS FINITE STATE MACHINE

Transcription

1 COMPUTATIONAL TOOL FOR AUTOMATIC DESCRIPTION OF TIM AND NCAP (IEEE STD. 1451) SPECIFIED IN XML AT HIGH LEVEL OF ABSTRACTION AS FINITE STATE MACHINE Tiago da Silva Almeida 1, Alexandre César Rodrigues da Silva 2, Daniel J. B. S. Sampaio 3 Abstract Advances in the development of new design methodologies and new algorithms have led to the emergence more complex electronic circuits. For this is required computational tools more complex and accurate to create electronic circuit designs. Thus, this paper presents a new methodology based in computational tool for automatic conversion of visual representation of finite state machines for textual representation. The finite state machine is modeled in Stateflow environment and converted to XML description following the SCXML specifications. As a case study was implemented and simulated at high level of abstraction four finite state machines, two ones of TIM and two ones of NCAP, all of them are based on IEEE std The experimental results showed that the proposed tool generates a faithful description in XML. Which it has a great applicability in the documentation and synthesis of dedicated hardware for exchange information between NCAP and TIM its own IEEE std Index Terms ESL, IEEE std. 1451, SCXML, Synthesis. different levels of abstractions. The model design flow is considered by [1] as an extended version of the Y diagram presented by [2] and [3]. At paper had still pointed out the problems of incompatibility between the tools and its weaknesses. The Figure 1 defines the steps of design of top-down methodology in an ideal model. One side corresponds to the steps of software creation, while the other side corresponds to the steps of hardware creation. Each side is divided into different levels of abstraction, e.g., Task and Instruction (software) or Components and Logic (hardware). There is a common level of abstraction, named ESL. In this level, we cannot distinguish between hardware and software. At each level, we can run a synthesis step (continuous vertical arrow) and the specification is transformed into an implementation. Horizontal dotted arrows indicate the step which we can change the models of individual elements in the implementation directly to the next level of abstraction (lower level abstraction). INTRODUCTION Nowadays, computational tools are indispensable in the electronic circuits design due to the increase in complexity of electronic circuits and the need to manage large amounts of data related to design. The development of new methodologies and tools has become a strategic area in the development of new technologies, in particular the development of CAD (Computer Aided Design) tools. CAD tools can be best understood as design information management systems, along with the creation of graphic based input and simulation of the designs created. These simulations can be used, shared, published, republished and reused in different formats, scales and levels of detail. But with so many studies involving different methodologies and computational tools, in [1], it was proposed a classification model for design and ESL (Electronic System Level) tools. The paper details the characteristics and different approaches of design computational tools, both for modeling at hardware and software level. Figure 1 illustrates the design flow in FIGURE. 1 FLOW ELECTRONIC SYSTEMS DESIGN, ALSO KNOWN AS DOUBLE ROOF MODEL. The graphical representation of electronic systems facilitates formal verification of the system and methodologies can be developed to aid in the synthesis steps. Such as literature related, we cite the paper [4] proposed an approach based in finite state machines (FSM) to automatic synthesis of decoders. In [5] was developed a methodology for synthesis of supervisors of distributed 1 Tiago da Silva Almeida, DEE, FEIS, UNESP - Univ Estadual Paulista, Av. José Carlos Rossi, s/n Campus III, Ilha Solteira, SP, tiagoalmeida@aluno.feis.unesp.br. 2 Alexandre César Rodrigues da Silva, DEE, FEIS, UNESP - Univ Estadual Paulista, Av. José Carlos Rossi, s/n Campus III, Ilha Solteira, SP, acrsilva@dee.feis.unesp.br. 3 Daniel J. B. S. Sampaio, DEE, FEG, UNESP Univ Estadual Paulista, Av. Ariberto Pereira da Cunha, 333, Guaratinguetá, SP, dsampaio@feg.unesp.br.

2 production line based on FSM. In [6] was developed a probabilistic methodology for diagnosis of fault detection in FSM based on a possible output sequence corrupted. In [7], the authors presented a method of FSM reengineering, rebuilding it with a different topology, but with equivalent functionality. In [8], it was developed a complete approach to modeling decoders for communication systems. The approach was based on FSM, being able to identify whether the decode exists or not. Thus, this paper presents a methodology for ESL designs based in computational tool. From this methodology was developed a computational tool named SF 2 XML (Stateflow to extensible Markup Language). This tool is capable to read a file with a state transition diagram in Stateflow environment [9] and generate a textual description in XML [10]. The proposed methodology is in specified and implemented in systems level, because it is not possible see the difference between hardware or software implementation. As case study, was used four FSM from IEEE std Two ones from TIM (Transducer Interface Module) represent a controller and the communication operation with the NCAP (Network Capable Application Processor). Two ones from NCAP represent a controller of actives transducer in TIM and correction errors in operation of theses transducer. It is important to highlight the exchange information between the NCAP and TIM. For this communication the IEEE std propose use XML schemes, but we propose use SCXML (Statechart XML) and our tool. Thus, the contribution of this paper can be listed like: A new methodology to convert FSM in Stateflow in a textual description using a standardized language; Portability of chosen language to publish, share and reuse the FSM; With the IEEE std case study a new and easier method to implement and exchange information between the NCAP and TIM. IEEE STD The goal of IEEE std is to define a set of communication interfaces to connect transducers based in macro processed systems and define one or more field buses in an independent environment [11][12]. The standard family is divided in two parts. The first one defines a set of hardware interface to connect transducers to a microprocessor or an instrumentation system. The second one defines a set of software interface to connect transducers to different network control technologies. The IEEE std provides the interoperability of the systems and the plug and play capacity of transducers [12][11]. The basic structure of blocks of IEEE Std can be explained as illustrated in Figure 2. FIGURE. 2 BLOCK STRUCTURE OF IEEE STD The IEEE std is divided in committees, which one specifies a different field bus to connect transducer organized in network. The key feature of the committees is the TEDS (Transducer Electronic Data Sheets) definitions. The TEDS are memory devices linkage to transducer to storage: manufactory data, identification, calibration, among other data associated to transducers. This way, a new transducer connect to the field bus can be automatically recognized [11][12]. The IEEE std is formed by following committees: IEEE std , IEEE std , IEEE std , IEEE std , IEEE std , IEEE std , IEEE std The standard does not specify the kind of hardware or technology must be used, it specifies only the interface, the common protocol and the TEDS specifications to implemented in future technologies. Transducer interface module (TIM) The TIM is controlled by NCAP in a standardized interfaces. This feature allows the operation of transducers in measurement systems and distributed control. The TIM functionality can be described by mean three operations states: TIM initialization (TI), active TIM (AT) and inactive TIM (IT). The TIM is placed in TI state by a reinitialization command (CI) or by external event of turn on the system. Once completed the process of initialization is going to occur a transition through to AT state and it is going to wait for next command, such as Figure 3. FIGURE. 3 REPRESENTATION OF OPERATION STATES OF TIM.

3 The IT state is going to active only by men sleep commando (SC) and to reactive can be send an active command (AC), custom command (CC) by designer or when temporizer command (TC) from IT state. TIM message commands The logical communication between the NCAP and TIMs or between TIMs is by this Module Communication. The Receive interface is provided by the IEEE std committee and is called by the IEEE 1451.X layer when incoming communication messages are received by the IEEE 1451.X layer across the linkage [13]. The Module Communication can be better understood by mean of state transition table in Table I. The outputs are marked like don t care because the output in each state is the behavior itself state and the inputs are methods or events to trigger the transition. TABLE I COMMUNICATION FINITE STATE MACHINE OF TIM WITH NCAP OR ANOTHER TIM. Idle 4 Writing WriteMsg() X Idle 4 Close 5 close() X Writng 1-Last? X X Writng Aborting Abort() X 1-Last? OneWay? [last=true] X 1-Last? Writing [last=false] X OneWay? ReceivePending [oneway=false] X OneWay? Idle 4 [oneway=true] X ReceivePending Reading NotifyResp() X ReceivePending Aborting Abort() X Reading 2-Last? X X Reading Aborting Abort() X 2-Last? Idle 4 [last=true] X 2-Last? Reading [last=false] X Aborting Idle 4 Open() X Another important factor about the TIM implementation is the messages protocol sent and received between NCAP and TIM. The IEEE std contains the specifications of as the protocol must work [14]. The IEEE std committee define the message structure sent by means ICM (Interface Communication Module) to create a communication protocol. The message structure sent by means standard interface must has in its own structure an octets group with fields: Channel number of destiny transducer: It indicates the channel number of destiny representing by 2 bytes; Command class: It indicates the command class when the transducer is in operation state; Command function: It is the function to be executed defined according with the command class; 4 Initial state. 5 Final state. Size: It is formed by 2 octets indicating the octet number of message, i.e., how many octets are expected in field data; Data: It represents field data; This paper was considered only receipt of TIM messages and these messages are fit to be read for the FSM in Table I. Network capable application processor (NCAP) The NCAP is a network node capable of receiving data as well as high or low level of abstraction via an external network or locally, process the data and send to TIMs through a standardized interface [14]. The Function Block is the primary mechanism for the abstraction and packaging of application functionality. These functions can be understood like any functionality in NCAP, e.g., recognition a TIM, management a TIM, treatment of information, publication of information, etc [15]. Its FSM is presented in Table II. The same way in Table I the inputs are methods or event and the outputs are don t care. TABLE II FINITE STATE MACHINE OF NCAP FUNCTION BLOCK BEHAVIOR FB_IDLE 4 FB_RUNNING Start() X FB_RUNNING FB_IDLE 4 Clear() X FB_RUNNING FB_STOPPED Pause() X FB_STOPPED FB_RUNNING Resume() X FB_STOPPED FB_IDLE 4 Clear() X In IEEE std the Transducer Block is modeled to contain a register corresponding to each TIM register. A second set of registers contains values mapping the contents of the raw data registers using the correction information provided by the TIM TEDS [15]. The correction FSM may reflect both corrections performed within the TIM Block and within the transducer itself. The FSM correction is applied to the transducer as a whole. If an implementation with several transducer channels permits some channels to be corrected while others are uncorrected, the Transducer Block must be implemented to place all channels in either the corrected or uncorrected mode consistent with the FSM [15]. The FSM as state transition table is presented in Table III using the same representation in Table I and Table II. The state Tb_Correted2 and Tb_Uncorreted2 represent the correction behavior is active in the NCAP to the TIM. TABLE III FINITE STATE MACHINE OF NCAP FOR ERRORS CORRECTION FROM PHYSIC INTERFACE. Tb_Correted1 4 Tb_Correted2 GoActive() X Tb_Correted1 4 Tb_Uncorreted1 Disable X Tb_Correted2 Tb_Correted2 Disable X

4 or Enable Tb_Correted2 Tb_Correted1 1 GoInactive() X Tb_Uncorreted1 Tb_Uncorreted2 GoActive() X Tb_Uncorreted1 Tb_Correted1 1 Enable X Tb_Uncorreted2 Tb_Uncorreted2 Disable X or Enable Tb_Uncorreted2 Tb_Uncorreted1 GoInactive() X METHODOLOGY For acceptance in the community of software development, maintainability and practicality, we chose to develop the translation environment using an object-oriented approach. Robustness was chosen by the C++ language. Thus, common features between methods were coupled to objects, so was created a logical interaction with low representational gap. The proposed tool in this work, called SF 2 XML, is able to capture relevant information in the project file Stateflow environment and generate a corresponding description in XML. The resulting file conversion is also in accordance with international standards of default file in case the SCXML proposed by W3C (World Wide Web Consortium). The SF 2 XML has four classes of objects, an object that makes up the logical structure of storage memory at runtime, an object of reading the file Stateflow and extraction of relevant information, an object to generate the syntactic and semantic file XML and other objects to make interfacing with the user. The tool is also able to identify sub-fsm, so it has recursive methods for FSM hierarchical cluster automatically, which generates a certain economy of code and maintenance. The SF 2 XML has the follow algorithm: 1) Reads MATLAB / Simulink file and identify the FSM; 2) Store the state or transitions and its information; a) If the state has a sub-fsm store the first transition in this sub-fsm, otherwise go to step 2(b). b) Verify which type this FSM is (Mealy or Moore); 3) Start write XML file; a) Seeking relationship between states of the same hierarchical level and which state is the first in highest level; b) Write the state tags, the transition related to this states; c) If there is a sub-fsm decrease the level hierarchical and go to step 3(a), otherwise go to step 3(d); d) While there is a state such that is associated with a transition go to step 3(a). 4) Return the XML file. TIM AND NCAP SPECIFICATION IN SYSTEM LEVEL I. This sub-fsm is able to understand the message sent by NCAP, through interpretation of a simple and dedicated grammar. We considered only four channels coupled to TIM, two classes of commands: one for the TEDS data access and data access to the transducer and two possible functions for these data: reading and writing. Soon, the regular expression that represents the string read by this sub- FSM is: (0^*+1^*+2^*+3^*)(1^*+3^*)(2^*+3^*). Figure 4 illustrates the FSM for the TIM Stateflow environment. The state A1 represents the initial state responsible for reading the first data, the states A2 to A5, representing the channels 0 to 3, respectively, the state A6 is the command class for TEDS, the state A7 is the command class to the transducer, the state A8 is the read function and the state A9 is the function writing. FIGURE. 4 FSM REPRESENTING THE COMPLETE IMPLEMENTATION OF THE TIM. This implementation of the TIM was set so that the FSM of Figure 4 works as a transducer controller module. Therefore, considerations such as the size of the data and their data were excluded, since these data can be accessed through an external memory, for example. As the TIM it is a controller module, it has two inputs and four outputs. The two inputs are: a switch activation TIM and a serial input for reading the string control coming NCAP. The outputs are: signaling the state of TIM (on, active = 1, inactive = 0), signaling that the selected channel (ca, channel 0, 1, 2 or 3), signaling that the class command and signaling which function has been selected (f). These outputs can be used to select the read or write (reading = 0, writing = 1) or the TEDS transducer (cl, TEDS = 0, transducer = 1) in one of four channels. For a simple simulation of the FSM proposal, we used the following input vectors: ini = [ ]; msg = [ ]; (1a) (1b) The result of simulation for the vectors (1a) and (1b) is: channel = [ ]; (2a) For the development of the TIM in Stateflow environment was created a sub-fsm in AT to represent the FSM in Table class = [ ]; (2b)

5 function = [ ]; Active = [ ]; (2c) (2d) The FSMs in Table II and Table III were modeled and simulated individually, because its behavior is too different. Another factor is the level of abstraction, the FSM in Table II and Table III express an abstract behavior and it is need the system more concretely. Thus, the FSM in Table II was adapted too, as illustrate in Table IV to represent a digital circuit. TABLE IV FINITE STATE MACHINE OF NCAP FUNCTION BLOCK BEHAVIOR FB_IDLE 1 FB_RUNNING 1 1 FB_RUNNING FB_IDLE FB_RUNNING FB_STOPPED 1 0 FB_STOPPED FB_RUNNING 1 1 FB_STOPPED FB_IDLE The inputs and outputs were considered with a single bit. The bit 1 means the message to start the function e pass to state FB_RUNNING. The same way, the output in bit 1 means the state FB_RUNNING is active. To simulate this FSM was used the follow input vector and it obtained the output vector: input = [ ]; output = [ ]; (3a) (3b) The same way in previous FSM, the Table V is an adaptation of Table III and the bit 1 means the message to start the function e pass to state Tb_Correted2 and the output in bit 1 means the state Tb_Correted2 is active. TABLE V FINITE STATE MACHINE OF NCAP FOR ERRORS CORRECTION FROM PHYSIC INTERFACE. Tb_Correted1 4 Tb_Correted2 1 1 Tb_Correted1 4 Tb_Uncorreted1 0 0 Tb_Correted2 Tb_Correted2 1 1 Tb_Correted2 Tb_Correted Tb_Uncorreted1 Tb_Uncorreted2 1 0 Tb_Uncorreted1 Tb_Correted Tb_Uncorreted2 Tb_Uncorreted2 1 0 Tb_Uncorreted2 Tb_Uncorreted1 0 0 To simulate of Table V was used the follow input vector and it obtained the output vector: input = [ ]; output = [ ]; (4a) (4b) RESULT OF TRANSLATION The tool was able to accurately generate an XML representation corresponding to the diagram shown in Figure 4. Every XML description is according to SCXML specification. Listing 1 shows the description in XML generated by SF 2 XML. Listing 1. XML code representing the FSM of Figure <?xml version="1.0" encoding="iso "?> 2. <scxml version="1.0" xmlns=" initialstate="0"> 3. <state id="0"> 4. <transition event="input=1"> 5. <target next="1" /> 6. <assign expr="output=1" /> 7. </transition> 8. <transition event="input=0"> 9. <target next="0" /> 10. <assign expr="output=0" /> 11. </transition> 12. </state> 13. <state id="1"> 14. <transition event="input=0"> 15. <target next="2" /> 16. <assign expr="output=0" /> 17. </transition> 18. <initial> 19. <transition> 20. <target next="3" /> 21. </transition> 22. </initial> <state id="10"> 25. </state> 26. <state id="11"> 27. </state> 28. </state> </scxml> It is important to highlight that for convenience of space redundant tags were omitted in Listing 1 and states assumed a decimal representation continuously, regardless of whether the state is within another state or not. Table VI presents the relation of this decimal representation of the states in the XML file generated by SF 2 XML. TABLE VI DECIMAL REPRESENTATION OF THE STATES IN THE XML DESCRIPTION CORRESPONDING TO THE DIAGRAM IN FIGURE 4. State Decimal representation State IT 0 A4 6 TA 1 A5 7 TI 2 A6 8 A1 3 A7 9 A2 4 A8 10 A3 5 A9 11 Decimal represen tation Line 1 of Listing 1 specifies that it is an XML file, the XML version and encoding used. The tags of lines 2 and 30, specify the start and end of the FSM. In line 2 is also specified the version of SCXML used, the name for the XML document (xmlns) and the initial state of the FSM (initialstate= 0 ). The tag <state id=... > and </state> specifies the state and its identifier (lines 3, 12, 13, 24-28).

6 The tags <transition event=... > and </transition> to specify a transition that will occur according to a particular event, e.g. INPUT = 1 (line 4). If the transition occurs, the tag <target next=... /> specifies the next state of the FSM according to its identifier. The tag <assign expr= OUTPUT=... /> assigns a new value to the output attribute expr. If there are hierarchically nested state, states are chained between the tags <state id=... > and </state> (lines 13-28). However, the initial state is specified by internal tags <initial> and </initial> within a transition indicating to the initial state. The performance of SF 2 XML with the three cases was measure in seconds in a computer with Intel i5 1.7 GHz, RAM 6 GB and operation system Microsoft Windows 7 64 bits. Because of states quantity the TIM Operation FSM (Figure 4) spent more time to generate the XML about seconds. The case NCAP function block behavior FSM (Table IV) and NCAP errors correction (Table V) FSM spent and seconds, respectively. CONCLUSION This paper presented a new methodology for automatic conversion of visual representations of FSM to a textual description of it. The new methodology was implemented in a computational tool called SF 2 XML. This tool converts a given state transition diagram into an XML representation according to the specification in SCXML. As a case study we used an implementation of four FSM based in IEEE Std This is an important application, because the purpose of IEEE Std is the standardization of sensor networks industrial, so that there is interoperability between different systems. The experimental results with these case studies demonstrated the efficiency of the proposed methodology and tool. The conversion to XML is quite convenient because the portability of language allows for a wide applicability of the proposed methodology. E.g., documentation, level hardware or software, web publishing, using simulators such as XML and standard language to optimize in future works of FSM. Another important factor is that IEEE std suggests the utilization of XML scheme [13] to exchange information between NCAP and TIM at software level. Such as SCXML is simpler than XML scheme is highly indicated use it to exchange information about the system architecture. ACKNOWLEDGMENT The authors would like to thank the National Council for Scientific and Technological Development (CNPq, process: / and /2012-2). methodologies, IEEE Transactions On Computer-aided Design Of Integrated Circuits And Systems, vol. 28, no. 10, pp , [2] D. D. Gajski and R. H. Kuhn, Introduction new VLSI tools, IEEE Computer, vol. 16, no. 12, pp , [3] T. Riesgo, Y. Torroja, and E. Torre, Design methodologies based on hardware description languages, IEEE Transactions on Industrial Electronics, vol. 46, no. 1, pp. 3 12, [4] S. Shen, Y. Qin, K. Wang, Z. Pang, J. Zhang, and S. Li, Inferring assertion for complementary synthesis, Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol. 31, no. 8, pp , [5] R. Su, J. Van Schuppen, and J. Rooda, Aggregative synthesis of distributed supervisors based on automaton abstraction, Automatic Control, IEEE Transactions on, vol. 55, no. 7, pp , [6] E. Athanasopoulou, L. Li, and C. Hadjicostis, Maximum likelihood failure diagnosis in finite state machines under unreliable observations, Automatic Control, IEEE Transactions on, vol. 55, no. 3, pp , [7] L. Yuan, G. Qu, T. Villa, and A. Sangiovanni-Vincentelli, An FSM reengineering approach to sequential circuit synthesis by state splitting, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 27, no. 6, pp , [8] H.-Y. Liu, Y.-C. Chou, C.-H. Lin, and J.-H. Jiang, Automatic decoder synthesis: Methods and case studies, Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol. 31, no. 9, pp , [9] S. T. Karris, Introduction to Stateflow with applications. Orchard Publications, [10] R. Auburn, J. Barnett, M. Bodell, and T. Raman, State chart XML (SCXML): State machine notation for control abstraction 1.0, site, 2012, [11] E. Song and K. Lee, Interoperability Test of IEEE Standard- Based Wireless, in Measuring Technology and Mechatronics Automation (ICMTMA), 2010 International Conference on, vol. 2, 2010, pp [12] E. Song, K. Lee, S. Fick, and A. Donmez, An IEEE standard-based wireless sensor network with embedded WTIM, in Instrumentation and Measurement Technology Conference (I2MTC), 2011 IEEE, 2011, pp [13] IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Std , pp , [14] T. A. dos Santos Filho, Desenvolvimento de um n o de rede com diferentes interfaces de acordo com o padr ao IEEE 1451 utilizando o processador NIOS II e o sistema operacional embarcado uclinux, Ph.D. dissertation, Universidade Estadual Paulista J ulio de Mesquita Filho, [15] IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Network Capable Application Processor (NCAP) Information Model, IEEE Std , pp. i, REFERENCES [1] A. Gerstlauer, C. Haubelt, A. D. Pimentel, T. P. Stefanov, D. D. Gajski, and J. Teich, Electronic system-level synthesis