Toolchain and workflow for the design of an ISO compatible ECU based on ISOAgLib

Transcripción

1 Toolchain and workflow for the design of an ISO compatible ECU based on ISOAgLib Joaquin Ezpeleta and Sebastián Rossi, Facultad de Ciencias Exactas, Ingeniería y Agrimensura, Universidad Nacional de Rosario, Av. Pellegrini 250, S2000BTP Rosario, Argentina ezpeleta@fceia.unr.edu.ar, srossi@inti.gob.ar Abstract. This paper describes a basic toolchain for the design of an ISO compatible electronic control unit (ECU), from its conception to the implementation of a working embedded prototype, along with a suggested workflow for dividing application programming, mask design and hardware-related tasks in a debugging-friendly and time-efficient manner. The toolchain is centered on the open source ISOAgLib programming library distributed and maintained by OSB AG and the paper will refer to other specific tools and devices, but is otherwise intended to provide a general introductory overview of the process rather than focus on specific vendors or platforms. Keywords: toolchain, workflow, ISO 11783, ISOBus, ISOAgLib, controller area network (CAN), embedded system. 1 Introduction ISO [1 et seq.] commonly known as ISOBus defines a serial data network for agricultural or forestry equipment based on the CAN 2.0 B [4] protocol. It is intended to provide an interconnection system for on-board electronics. A typical ISOBus network is shown on Figure 1. A basic element of such network is the electronic control unit (ECU), which is defined in [1] as an electronic item consisting of a combination of basic parts, subassemblies and assemblies packaged together as a physically independent entity. This paper describes the process for creating one such ECU, from its design to the implementation of an embedded prototype. Specifically, it suggests a toolchain and a workflow for this process. The toolchain is based on the open-source library ISOAgLib and other related tools distributed and maintained by OSB AG [7], but alternatives are given wherever possible to provide maximum flexibility. Similarly, the process described is mostly platform-independent (both in terms of the operating system used for development on a desktop environment and in terms of the embedded hardware platform used for the actual implementation), but examples are given at various points for the purpose of clarity and reproducibility. For an implementation on specific hardware see, for example, [6]. Section 2 presents the suggested toolchain, along with explanations and brief examples; Section 3 describes the physical and virtual elements needed to test and use ISBN

2 software- and firmware-level applications; Section 4 presents the proposed workflow for an efficient and debugging-friendly task division using the tools and resources presented in Sections 2 and 3. Fig. 1. Example ISO network on a tractor with two implements. 2 Toolchain A summary of the suggested toolchain is shown graphically in Figure 2. It presents the tasks needed to design an ISOBus system with ISOAgLib, the tools needed for each task and the relationship between these tasks. As will be seen on Section 4, however, many of these tasks can often be undertaken independently, so a roughly left-to-right and top-to-bottom order will be followed. 2.1 Mask design and parsing The first tool to be discussed is VT designer, which is a graphic interface for designing masks which are compatible with [3]. It is currently available from OSB AG in both a trial and a full version. It has a simple and intuitive interface and includes examples which can be modified to gain insight into its use. The purpose of this tool within the suggested toolchain is to take an abstract design concept for the necessary mask(s) and create files which can be further processed for use in the application. Given one or more manually-loaded masks (collectively, an object pool), VT Designer creates a.vtp project file and a number of.xml files which contain the actual objects and attributes. An alternative for the use of VT Designer is PoolEdit, developed by Matti Öhman and Jouko Kalmari at Aalto University [9] and distributed under GNU General Public License (GPL). The former is discussed here for its greater affinity with the OSB AG toolchain, but the latter produces almost identical results. ISBN

3 Fig. 2. Toolchain for the development of an ISO compatible application. The.xml files output by VT Designer cannot typically be included directly into the source code of the application. A second tool is needed to transform the.xml files into source files which can be handled by the C++ compiler. An example of an application which serves this purpose is vt2iso.exe, available free of charge from OSB AG. It is a console application which essentially takes the.vtp and.xml files from the previous step and produces a group of.inc and.h files which can then be included directly by the compiler. Below is a basic use example on the Microsoft Windows command line, where mydisplay.vtp is a VT Designer project file. A number of optional arguments are also available but are not typically necessary. C:\IsoAgLib\tools\vt2iso\bin>vt2iso.exe mydisplay.vtp ISBN

4 2.2 Project Configuration Another step in the design process is defining project settings. These are to be entered manually in a configuration file and include basic parameters, such as the project name, the folder where the user and library files are stored, the number of CAN instances and the target platform (e.g. PC running Microsoft Windows, PC running Linux, embedded system, etc.), among others. It is advisable to adapt the template (conf_template) included with ISOAgLib rather than enter the settings directly on a blank file, as the former approach will be both faster and less error-prone. In either case, the resulting file is to be processed by a shell script (conf2build.sh) to produce a configuration header (isoaglib_project_config.h) which can be included directly into the application. The shell script is included with ISOAgLib and can be run natively in Linux and other UNIX systems. Microsoft Windows users will need to install MSYS/MINGW [11] or other similar software which makes it possible to run UNIX shell scripts under this OS. A typical command for executing the script is shown below, where myconfig is a copy of conf_template adapted to a specific project. $ conf2build.sh myconfig Also note that the resulting isoaglib_project_config.h header is included via the library header isoaglib_config.h and is not to be included directly (the preprocessor will issue an error if it is). 2.3 Hardware Abstraction Layer (HAL) ISOAgLib includes a Hardware Abstraction Layer (HAL) which acts as an intermediary between the rest of ISOAgLib and the actual hardware on which it runs. This includes system startup, time tracking, power management, CAN communication, non-volatile storage and similar hardware-dependent functions, along with definitions for data types, error codes and configuration parameters. The HALs for certain hardware platforms (most notably, PCs running Microsoft Windows or Linux) are already included with the library, but others must be programmed by the user (e.g. ARM-based MCUs). It is advisable to use an existing HAL as model when creating a new one. It should also be borne in mind that, when changing platforms, the project configuration described in 2.2 must be updated accordingly. In embedded systems, it may also be necessary to include additional files outside the HAL, such as a startup file (see Figure 2, bottom left). 2.4 User Code While ISOAgLib provides for most communication and compliance requirements, it is up to the user to design and program the actual application. The typical application includes initialization code which is run once at the start, a main application loop ISBN

5 which performs all communication and normal operation tasks and closing code which shuts down the application and all associated hardware in a controlled manner. In addition, on embedded systems, startup code is typically needed before the rest of the application can be executed. The initialization code should perform the following basic functions: (a) initialize instances of the system, the scheduler, the bus, the monitor and the CAN controller; (b) declare or retrieve parameters needed for subsequent address claim; (c) register the necessary tasks on the scheduler, initialize the system components and register the object pool on the monitor; (d) transfer control to the main loop. In addition, it should perform any application-specific or hardware-dependent initialization functions (such as interrupt vector, watchdog, real-time clock, analog-digital converter or output configuration or pin remapping), although these can usually be called automatically during system initialization by including them in the HAL. The main application loop should run after initialization and until the application needs to terminate for any reason. As far as the ISOAgLib library is concerned, the only requirement for the main application loop is that the time event of the scheduler instance be called within the time constraints defined in [1 et seq.], but other functions will be needed for any specific application. Finally, the closing code unregisters all elements, deallocates memory, calls the close method for each of the active instances and takes all associated hardware to a safe condition (e.g. deenergized actuators). Gaining insight into the use of ISOAgLib can be challenging given the lack of freely available training and tutorials. OSB AG offers customized workshops and training sessions which include examples, but the examples themselves cannot be bought alone. If workshops or training are not an option due to cost, examples are freely available for earlier versions of ISOAgLib (up to 2.2.1) from OSB AG s repository. These can be adapted to more current versions by following the changelog and inferring necessary changes in the user files, but this involves considerable guesswork and can be a time-consuming process. 2.4 Compilation, Linkage and Loading The tools used for compilation, linkage and (in the case of embedded systems) loading are highly platform-dependent and are usually managed by a single IDE. General purpose compilers such as GCC [10] can be used for early stages of development where the application is to run entirely within the desktop environment, while vendor- or platform-specific compilers are generally needed to compile the application for specific hardware (e.g. armcc for ARM-based MCUs). Remark 1. ISOAgLib is written in C++. This must be taken into account when selecting the product and compiler, as some products do not offer C++ compilers or do so at relatively high prices. ISBN

6 3 Hardware framework Figure 3 shows an example interconnection of system elements. It is intended to provide a summary of the connection options available throughout the entire design process. In each stage of the development proces, however, not all of the elements are simultaneously necessary in general. For example, while initially programming and debugging the application, all work is typically done within a desktop environment without resorting to additional external hardware. Similarly, the process for preliminary design and implementation of sensors and actuators will not normally require access to a virtual terminal, whether physical or simulated. The interconnection between system elements is done basically by means of three CAN buses, namely a physical bus, a socket bus and a proprietary virtual bus. The physical bus is an actual wired bus complying with the requirements set forth in [2]. It includes a pair of data wires CAN_H and CAN_L and should be terminated with impedance-matching resistors. Remark 2. While [2] defines a nominal characteristic bus impedance of 75 Ω, existing CAN hardware not developed specifically for ISOBus may use 120 Ω instead, as defined in [5] (the original Bosch document, [4], did not specify this and other electrical aspects of the physical layer). Data transmission from and to the bus is normally done through CAN transceivers. These convert 3.3 V or 5 V logic values from the RX/TX pins on an MCU (or other levels from other hardware) to dominant and recessive bits on the CAN bus and vice versa. Examples of CAN transceivers are SN65HVD230 and MAX3051 for 3.3 V systems and SN65HVD255 and MAX3058 for 5 V systems. The socket bus is an internal socket connection which emulates a CAN bus within a desktop environment. The ISOAgLib toolchain includes several similar tools for this purpose, one which is designed solely for interaction between several ISOAgLib applications within the desktop (can_server_simulating.exe) and others which additionally provide functionality for connection with vendor-specific hardware and software. For example, can_server_vector.exe and can_server_vector_xl.exe are designed for communicating with hardware and software from Vector Informatik GmbH [8], which is achieved by using Vector s CAN DLL library. The CAN server thereby acts as a bridge between the socket bus and the proprietary virtual bus, discussed below. The proprietary virtual bus is an emulated CAN bus like the socket bus, and can be thought of as an extension of the latter. It is used for communication between proprietary hardware and software from a given vendor and the corresponding CAN server. In addition, by communicating with a CAN card, the proprietary virtual bus in turn enables access to the physical external bus. For example, Vector offers CANcardXL, a two-channel driver card which provides access to up to two external physical buses. Additionally, they offer an application by the name of CANoe which manages the card and also serves as a bus analyzer. When both CANcardXL and can_server_vector_xl.exe are running, the socket bus, the proprietary virtual bus and the physical bus merge, for all practical purposes, into a single CAN bus. This and other similar setups offer great versatility, as they make it possible for a number of ISBN

7 applications running either on the desktop or on an embedded system to communicate seamlessly with each other and with third-party devices, such as a virtual terminal. In addition, software like CANoe can emulate a virtual terminal, which is essential for running preliminary tests entirely within the desktop environment, with further tests on actual virtual terminals being done at a later stage of development. Fig. 3. Hardware framework. In addition to the CAN buses, Figure 3 shows a UART connection between the MCU and a terminal emulator within the PC. This provides a simple means of transmitting debugging information between the PC and the MCU without loading the CAN bus, but is entirely optional. 4 Workflow This Section describes a proposed workflow for the design process of an ISO compatible application. The basic stages in this process are application programming (with and without masks), mask design, hardware-related tasks and prototyping. A way of organizing these stages is shown in Figure 4. The basic concept is to run tasks in parallel in order to make better use of available time, hardware and ISBN

8 human resources. Time is better used as different teams can work on the different task simultaneously. In addition, each task can be assigned to a specialist in the corresponding field, such as a programmer for building the application and an electrical engineer for working wiring, sensors and actuators, making better use of available human resources. Finally, available hardware can be used more efficiently, as each task requires only some of the hardware tools. Some examples of this were discussed in the previous Section, which described a flexible hardware framework. Fig. 4. Proposed workflow for the design process. ISBN

9 Another advantage of task division is to facilitate the debugging and troubleshooting process. When each task is undertaken individually, the possible error sources are confined to a subdomain of the entire system. For example, if the application is initially debugged using a virtual bus and simulated data (maskless application or application programming stage in Figure 4), no communication- or hardware-related errors arise and the debugging domain is thereby restricted only to the application itself. The maskless application programming stage consists in the design and programming of a virtual application which does not resort to any virtual terminal (physical or otherwise) for display. Additionally, such application would be developed entirely within a desktop environment, without resorting to external data or elements and without being loaded onto an MCU or other embedded system. The application uses the PC HAL at this point. As the application will be isolated from data which it normally needs for its operation (data from sensors, other network devices or user input), simulated data can be used during this stage to examine the behavior of the application in different situations. The mask design stage basically involves the task of designing one or more masks (an object pool) and parsing then into a format which can be handled directly by the compiler used for building the application. This stage can be completed mostly using the tools described in 2.1 above, although some previous design work is necessary to create a visual concept for the masks (colors, layout, shape and position of various elements, expected functionality, etc.). The application programming stage is an extension of the maskless application programming stage with the addition of the masks designed in the mask design stage. The goal of this stage is to ensure that the application can upload the object pool to a simulated virtual terminal and interact with it (i.e. receive user input and make necessary changes on the elements of the object pool). Except for data flowing to and from the virtual terminal, the rest of the data used during this stage is still simulated. Similarly, the application continues to run within the desktop environment using a PC HAL. The hardware-related tasks stage encompasses all hardware or platform-specific tasks. These basically include the design and implementation of actuators, drivers, sensors, data acquisition means, the creation of a HAL for ISOAgLib if one does not exist for the intended platform and the inclusion or programming of other platformdependent elements which cannot be included within the HAL (such as a startup file). The creation of the HAL in turn involves implementing functions for CAN communication, configuration of interrupt vectors, watchdogs, real-time clock, analog-digital converters or outputs and pin remapping. Finally, the application (included the masks) can be loaded onto the embedded hardware and combined with sensors, actuators, CAN peripherals and other hardware elements to produce a working embedded prototype. This prototype can then be tested for minor bugs or problems within a laboratory environment (possibly using a simulated VT) to create a final version of the device, which can be further tested with actual equipment on field prior to its commercial production. ISBN

10 References 1. ISO :2007, Tractors and machinery for agriculture and forestry Serial control and communications data network Part 1: General Standard for mobile data communication, International Organization for Standardization, Geneva (2007) 2. ISO :2002, Tractors and machinery for agriculture and forestry Serial control and communications data network Part 2: Physical Layer, International Organization for Standardization, Geneva (2002) 3. ISO :2004, Tractors and machinery for agriculture and forestry Serial control and communications data network Part 6: Virtual Terminal, International Organization for Standardization, Geneva (2004) 4. CAN Specification Version 2.0 Part B, Robert Bosch GmbH, Stuttgart (1991) 5. ISO :2003, Road vehicles Controller area network (CAN) Part 2: High-speed medium access unit, International Organization for Standardization, Geneva (2003) 6. Tumenjargal, E., Badarch, L., Kwon, H., Ham, W.: Embedded software implementation system for a human machine interface based on ISOAgLib. Journal of Zheijang University (2013) 7. OSB AG, 8. Vector Informatik GmbH, 9. PoolEdit - Open Source XML ISO User Interface Editor, 10.GCC, the GNU Compiler Collection, 11.MSYS, ISBN

11 A Fault Resilience Tool for Embedded Real-Time Systems Franklin Lima Santos 1, Flávia Maristela Santos Nascimento 2 1 Federal University of Bahia Department of Electric Engineering franklin_lima@ieee.org 2 Federal Institute of Bahia Department of Electro-Electronic Technologies flaviamsn@ifba.edu.br Abstract. Real-time systems have been used in many different areas such as medicine, multimedia and mechatronics. For such systems, it is important to meet both logical and timing requirements, since a malfunction may have undesired consequences. In this paper, we developed a simulation tool in MATLAB environment to deal with fault-tolerant real-time scheduling under Rate Monotonic scheduling policy, so that errors consequences can be envisioned, before system is put on operation. Keywords: Real-time systems, fault-tolerance, simulation, MATLAB. 1 Introduction Over the past decades computer designers focused their attention on developing what they considered a perfect computer project: computers had to be small, fast and cheap [12]. Indeed, their effort in reaching more performance at low cost and minimum size contributed remarkably for recent technological advances, especially those related to hardware improvements. The remarkable growth of electronic devices and computing systems in our daily activities has been boosting mechatronics, as a subarea of automation due to its ability of integrating electronic components and systems [4, 7]. The main elements of a mechatronic system can be observed in Figure 1. Fig. 1. Components of a mechatronic system [10]. ISBN

12 The user is the entity responsible for monitoring, super visioning and controlling the controlled object, which may be an airplane board control or an industrial plant, for example. Controlled objects are usually manipulated through human-machine interface (HMI), which is the element responsible for (i) translating control information to the user and (ii) allowing an interface between users and controlled objects. The control system is an interactive computer system that enables monitoring and changing the state of a controlled object, which is done through sensors and actuators [8]. The evolution of computer systems also allowed systems designers to focus on modeling, designing and implementation aspects of such systems aiming at developing applications with differentiated performance skills. At the same time, miniaturization of electronic components allowed computers to evolve from simply terminals to host control systems. For some of these applications correctness were not only associated with logical, but also with timing requirements. Indeed, systems in which correctness is associated not only with producing logically correct results, but also with the time at which such results are produced (timeliness) are known as realtime systems [2,5]. Real-time systems are present in many different areas such as medicine, avionics, multimedia and mechatronics [13]. For some of them, when timing requirements are not accomplished, the system may not achieve the expected level of Quality of Service (QoS). This is what happens, for example, in a video transmission (multimedia application). In worst cases, missing timing requirements may have undesired consequences as for example, if we consider an automobile ABS control, in which human life may be at risk [3]. This evidenced that different applications may have different criticality levels. Indeed, for "soft" real-time systems missing deadlines may not have more serious consequences, while for "hard" real-time systems missing deadlines may cause injuries for human beings and/or environment [2, 9, 11]. Since temporal requirements play an important role for real-time systems, it is crucial to have means of guaranteeing such requirements. In fact, both scheduling policies and schedulability analysis are responsible for ensuring timeliness for such applications. To do so, system tasks are ordered according to a specific scheduling policy and a subsequent schedulability analysis is performed to assess timeliness of each task. We detail such aspects in Section 2. Ensuring reliability is an important goal to be achieved for real-time systems. However, in terms of computational applications, the only certainty we have is that all of them may potentially fail [1]. In fact, system correctness relies on its dependability, a concept which discussed in Section 3. Also, since faults cannot be avoided and are difficult to predict [9, 11], taking such events into consideration is almost an obligation, if someone needs to guarantee QoS for real-time applications or even avoid more serious consequences. In this paper we investigate the impact of errors in real-time applications considering a specific scheduling policy. To do so, we defined a simulation environment, presented in Section 4 and developed a simulation tool, detailed in Section 5, which aims at measuring fault resilience for a particular set of real-time systems. Last, in Section 6, some conclusions and future works are drawn. ISBN

13 2 Real-Time System Overview A real-time system is a computer system in which both timing and logical requirements must be respected. Thus, the correct behavior of such a system depends not only on the integrity of produced logical results (also known as "correctness"), but also on the time at which they are produced ("timeliness") [2]. Examples of real-time systems include current control laboratory experiments, vehicle control, nuclear plants and flight control systems [13]. Usually, real-time systems are structured as a set of n periodic tasks Г = {τ 1, τ 2, τ n }. A given task τ i represents a function, routine (or subroutine) or any code snippet. Each task τ i has attributes such as an execution cost C i, a deadline D i, an activation period T i and a recovery execution cost C i. Thus, a periodic task can be described as an ordered tuple τ i = (C i, T i, D i, C i ). Tasks are executed in a specific order called execution scale. Such a scale is defined based on some heuristics, known as scheduling policy. Several scheduling policies have been addressed in literature and most of them are priority oriented [3, 9, 10], which means that tasks are ordered according to its priority. A well-known priority oriented scheduling policy is Rate Monotonic (RM), according to which tasks with shortest periods have higher priority. Clearly, this is a fixed-priority policy, since tasks period are defined offline and do not change during system execution. After a scheduling policy is chosen for a given task set Г is it important to assess if any task τ i ϵ Г may miss its deadline. To do so, we perform some tests, also known as schedulability analysis, which aims at determining if a given task set is feasible. In other words, such tests determine if any task τ i ϵ Г misses its deadline. Clearly, schedulability analysis is strongly linked with the chosen scheduling policy. In this paper we address the analysis based on Processor Utilization Analysis, which is discussed in Section Processor Utilization Analysis According to this approach, the schedulability of a given task set is assessed based on processor use. Indeed, processor utilization U, for a given task set Г composed of n a periodic and independent real-time task is given by: (1) Regarding Rate Monotonic, if we assume a periodic task set Г in which tasks period are equal to their deadlines, we state that Г is schedulable if: (2) ISBN

14 For RM, Processor Utilization Analysis is a sufficient schedulability test, which means that it is not able to ensure schedulability for all task sets. In fact, it has been proven that [6] if: (3) The task set is schedulable with RM. Otherwise the analysis does not guarantee schedulability. Also, Rate Monotonic is considered an optimal algorithm for systems in which tasks period are equal to their deadlines (T i = D i ) [6]. 3 Fault-Tolerant Real-Time Systems Faults are random events that cannot be predicted or avoided. Actually, the only certainty we have is that all computational applications potentially fail [1]. Indeed, a fault may be caused by several different events, as for example cosmic radiation, hardware fatigue or malfunctioning, specification and/or implementation aspects. A system is said to fail when there is a transition from an expected correct behaviour to an incorrect and unexpected behaviour. In other words, a fail represents a deviation from specification. The error is the state that leads the system to fail and faults are the causes of an error, which may be physical or algorithmic [1]. Indeed, applications must provide confidence in the expected operations, a concept usually addressed as dependability, which is related to some attributes such as availability, reliability, safety and maintainability [1, 14]. In terms of real-time system there is a concern about fault tolerance aspects, since a fault may affect the system schedulability, or in other words, may prevent tasks to meet their deadlines. For this reason, faults are considered as a threat to dependability. Thus, techniques must be implemented to deal adequately with faults, so that applications keep their correctness even in the presence of such events [1, 14]. Faults are more commonly classified based on the persistence criterion, according to which they can be transient, intermittent or permanent. Transient faults occur only for a given time and then disappear. An example could be electromagnetic interference. When a transient fault occurs repeatedly it is called intermittent, as for example a loose contact on a connector. Both transient and intermittent faults are difficult to diagnose. Last, permanent fault is one that continues to exist until the faulty component is repaired, as for example a lack of connectivity between two nodes in a network [10, 14]. In this paper we investigate the effects of transient faults focusing on techniques that can be used to deal with such faults, which are based on temporal redundancy. This consists of repeating the computation in time, or in terms of scheduling can be understood as re-executing a task (see Figure 2) or executing an alternative task (see Figure 3) until the system is put on a safe state [9,11]. ISBN

15 Fig. 2. Recovery based on re-execution of Task 1 under RM} Figures 2 and 3 presents a periodic task set being scheduled, where Г = {τ 1 = (1,2), τ 2 = (1,5)}. Observe that in Figure 2 an error occurred at t = 3 (red arrow), which affect Task 1. The faulty task re-executed immediately since there were no other higher priority task to execute. On the other hand, in Figure 3, an error affected Task 2 at t = 6 (red arrow), but it only could recover at time t = 7, since Task 1 was already released for execution and has a higher priority than Task 2. Fig. 3. Recovery based on the execution of an alternative version of Task 2 under RM. In the following sections we present the developed tool which focus on measuring the resilience of hard real-time systems scheduled according to RM scheduling policy. 4 Simulation Environment 4.1 System Model The assumed system model considers a task set Г composed of n independent and periodic real-time tasks Г = {τ 1, τ 2, τ n }. Each task τ i is represented by a tuple τ i = (C i, T i ) where C i is the constant worst-case execution time (wcet) of each task and T i ISBN

16 is the activation period. Also, we assume that the deadline for each task is the same as its period (T i = D i ). Tasks are scheduled according to Rate Monotonic, since this algorithm deals with fixed priority tasks and is widely used for embedded critical applications. Also, schedulability analysis is performed with Processor Utilization Analysis. 4.2 Fault Model Assuming a specific fault model is a difficult task since faults are random and cannot be predicted. We consider that the system is subject to multiple transient faults which can occur at any time instant. Also, we represent the fault resilience of a given system through the maximum number of errors the system can handle and keep its correct behavior. To do so, we use a random function in MATLAB to generate the number of errors that will affect each system. Also, the time instant in which errors occur is also determined through a random procedure. We discard errors that occur at time instants in which no task is executing, since such errors will not affect system behavior. We assume that fault detection occurs implicitly, at the end of each task execution, since the focus of the work is not the detection procedure, but system behavior after recovery strategies. 4.3 Recovery Model The recovery model describes the strategy used to put the system in a safe state. Indeed, we consider two possible actions: (i) faulty task re-execution or (ii) execution of an alternative task. Both strategies are defined offline, before running the system, and are performed in idle time instants available in execution scale. 5 Simulation Tool The general overview of the developed tool can be seen in Figure 4. The tool was developed in MATLAB, due to its versatility on numerical analysis, encapsulated functions and graphics. Fig. 4. Framework of Simulation Environment ISBN

17 The first step to use this tool is to input a schedulable task set. In case the user has no previously generated task set, it is possible to generate a random one inside developed environment. To so, the user only has to choose the number of tasks to be generated. In case the tool generates the task set, it also tests if it is schedulable, through processor utilization analysis. After, the user has to generate the number of errors that will affect the task set. As mentioned before, such a number is randomly generated by the tool. The user only defines a lower and upper bound, which will represent the interval in which the number of errors will be in. Based on the number of errors, the tool generates random time instants in which errors will occur. The screen of MATLAB running the simulator can be seen in Figure 5. Fig. 5. Screen shot of MATLAB running simulator. The simulation environment will generate an execution scale, which takes into consideration Rate Monotonic, as scheduling policy, the defined recovery scheme (reexecution or alternative task code) and the time instants in which errors occur. Based on those values, the system resilience is defined and results can be graphically checked. Briefly, the simulator executes the following steps, given the inputs described in Figure 4: Identify tasks affected by errors; Identify idle time after each faulty task, which can be used for recovery; Verify the possibility of re-executing the faulty task or executing an alternative code, respecting tasks priority (including the simultaneous verification of space for recovery and maximum execution time); Graphically analyze the resilience of the system, through graphically generated execution scale. Inform the number of errors and time instant which makes the system unschedulable. ISBN

18 To make things clear let us consider the following example: Example 5.1. Assume a task set Г = {τ 1, τ 2 } composed of two independent and periodic tasks where C = (3, 3) and D = T = (8, 12). Tasks are scheduled according to RM and in case of faults, tasks are re-executed. In other words, C i = C i. Fig. 6. Execution Scale for Example 5.1. The system is simulated during the hyperperiod h = lcm(8, 12) = 24 1 to ensure that all system execution will be considered. Fig. 7. Idle processor time for Example 5.1, graphically represented in tool. The first chart presented in Figure 6 presents the execution scale for the given task set. The random number of faults that this task set is subject to is n f = 2 and the random time instants in which they occur was t f = (3, 18). This is shown by a red mark in the chart. Detected errors are indicated by green circles. Figure 7 evidences the idle processor time, which are represented in blue. Finally, Figure 8 presents the fault-tolerant real-time schedule. Fig. 8. Fault Tolerant Scheduling for Example 5.1 assuming errors at t f = (3, 18). 1 lcm(x, y) is the function which calculates the least common multiple of input parameters,in this case, x and y. Usually systems are simulated during the hyperperiod, since it contains all system behavior. ISBN

19 It is important to mention that depending on the time instant that errors occur, the system may not be schedulable, even if it is subject to the same number of errors. Observe Figure 9, which presents the same task set described in Example 5.1 subject to two errors that happens at t f = (2, 3). Fig. 9. Execution Scale for Example 5.1 assuming errors at t f = (2, 3). Observe that in this case, recovery of both faulty tasks is not possible, since the available idle time (same as presented in Figure 7) is not enough for recovering tasks τ 1 and τ 2. before their respective deadlines. The graphic presented by simulator is according to Figure 10, confirming that the fault-tolerant scheduling is not feasible. Fig. 10. Fault Tolerant Scheduling for Example 5.1 assuming errors at t f = (2, 3). 6 Conclusions and Future Work Real-time systems have been used in a wide range area, as for example to control industrial processes. For most of these applications, missing timing requirements imply in a loss of Quality of Service or in worst cases may cause social, economic and/or environmental injuries. In this context, it is extremely necessary to deal with unpredictable and random events, such as faults, so that they interfere minimally in systems operation. In this paper we developed a simulation tool in MATLAB environment to deal with fault-tolerant real-time scheduling, so that errors consequences can be envisioned, before system is put on operation. One of our goals is to have an approximation between theoretical and practical models. This will enable more detailed studies and previous use of simulations before the applications are put into production. As future work we aim at simulating more robust systems, to evaluate better our preliminary results. Also, we focus on extending scheduling policies, so that EDF [6] is also considered. ISBN

20 7 Thanks The authors would like to thank the Federal Institute of Bahia (IFBA) for all support and National Council for Scientific and Technological Development (CNPq) for funding this work. References 1. Algirdas Avizienis, Jean-Claude Laprie, Carl Landwehr, and Brian Randell. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1):11 33, Jean-Marie Farines, Joni da Silva Fraga, and Rômulo Silva de Oliveira. Sistemas de Tempo Real. Departamento de Automa c ao e Sistemas - Universidade Federal de Santa Catarina, Florianópolis, Santa Catarina, Sunondo Ghosh, Rami Melhem, and Daniel Moss e. Fault-Tolerant Scheduling on a Hard Real-Time Multiprocessor System. In Proccedings of Eighth International Symposium on Parallel Processing, pages , April Rolf Isermann. Modeling and design methodology for mechatronic systems. IEEE/ASME Transactions on Mechatronics, 1(1):16 28, Li Jie, Guo Ruifeng, and Shao Zhixiang. The Research of Scheduling Algorithms in Real- Time System. In International Conference on Computer and Communication Technologies in Agriculture Engineering (CCTAE 10), volume 1, pages , June C. L. Liu and James W. Layland. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. Journal of the ACM, 20(1):46 61, Ren C. Luo. Sensors and actuators for intelligent mechatronic systems. In 27 th Annual Conference of the IEEE on Industrial Electronics Society, IECON 01, volume 3, pages , Paulo Eigi Miyagi and Emilia Villani. Mecatrônica como solução de automação. In Revista Ciências Exatas. Universidade de Taubaté, Flávia Maristela Nascimento, George Lima, and Verônica Cadena Lima. Deriving a fault resilience metric for real-time systems. In Workshop de Testes e Tolerância a Falhas, August Flávia Maristela Santos Nascimento. A Simulation-Based Fault Resilience Analysis for Real-Time Systems, George Lima, Flávia Maristela Santos Nascimento, Verônica Lima. Fault resilience analysis for real-time systems. In Proceedings of the 1st International Workshop on Analysis Tools and Methodologies for Embedded and Real-Time Systems, pages 35 38, Brussels, Belgium, October Mircea R. Stan and Kevin Skadron. Power-Aware Computing. Computer, 36:35 38, December John Stankovic. Misconceptions about real-time computing: a serious problem for nextgeneration systems. Computer, 21(10):10 19, Andrew S. Tanenbaum and Maarten van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, ISBN

21 Sievert-type measurement and acquisition system for the study of hydrogen storage in solids Jorge Runco, Marcos Meyer IFLP Departamento de Física Facultad de Ciencias Exactas UNLP CONICET { runco, meyer }@fisica.unlp.edu.ar Abstract This paper shows the development and implementation of a system to determine and analyze parameters of interest in the study of hydrogen absorption and desorption mechanisms in solids using the Sievert volumetric method. The experiment is controlled through a PC-type computing system by automatically measuring, controlling, recording and graphing the evolution of variables (pressures and temperatures) according to a set of previously programmed parameters. The manual monitoring, adjustment and operation option is also available to tune the experiment. The software was developed in a high-level programming language (Delphi) which offers the user a graphical interface typical of visual languages. In addition, results for applying the present system to typical ternary hydrides are presented. Key words: hydrogen storage, processes, absorption and desorption, data acquisition. 1. Introduction One of the most important challenges for the development of hydrogen utilization as an energy vector is the possibility of storing it in a safe and effective way [1]. Hydrogen in a gaseous state occupies a very large volume and requires very high pressures in storage reservoirs whereas, in a liquid state, it needs reservoirs at very low temperatures. Since hydrogen is highly reactive, there is a significant number of elements capable of reacting with it to form hydrides under appropriate pressure and temperature conditions. Hence, hydrogen storage in a solid state appears as a more effective alternative in terms of volume with respect to the other methods mentioned above. Absorption in metals, which forms a hydride phase, has many advantages over current systems (compression and liquefaction), since it does not require compressing and liquefying tasks or cryogenic temperatures. An important aspect in experimental research is the analysis of hydrogen absorption-desorption properties of new materials, as well as the study of absorption and desorption kinetics. As considerable pressure changes involve relatively small mass quantities, using volumetric techniques is especially suitable for this kind of research (mainly considering that hydrogen is the lightest element of all). 2. Measurement system description The equipment is based on a Sievert-type system [2], which allows studying hydrogen absorption-desorption kinetics at different temperatures, keeping pressure level constant in the reaction chamber, in a wide range of temperatures (from 300 K to 1000 K) and pressures (from 1 mbar to 50 bar). ISBN

22 Figure 1. Schematic diagram of the Sievert apparatus. The measuring instrument was developed based on a PC-type computing system which incorporates a 12-bit general purpose A/D interface [3], 5 inputs of which are used to measure analog magnitudes 4 for pressures and 1 for temperature. It also has digital outputs for the automatic opening and closing of the 7 solenoid valves (V1, V2, V3, V4, V5, PV1 and PV2) of the measurement system. The schematic diagram above illustrates the location of pressure sensors [4] in the experiment as well as valves automatically actuated by the control system. The measurement system has a furnace and a temperature controller to conduct the experiment at different sample temperatures. This controller communicates with the computer by means of an RS-232 interface and MODBUS protocol [5]. A flowmeter was added to the system to control and measure gas flow during the experiment. This device communicates with the computer also through an RS-232 interface and the MODBUS protocol. The software developed makes it possible to open and close solenoid valves at any desired time, to acquire and store parameters of interest pressures, temperature and flow and to preset temperature and flow values (setpoints) before starting the experiment. In addition, routines necessary to communicate with furnace and gas flow controllers through the MODBUS protocol were implemented. During the course of the experiment, the abovementioned parameters are acquired and stored, valves open and close when pressure conditions set before starting the measurement are met or for controlling gas flow with the flowmeter, and the system is capable of performing the experiment at a constant temperature, with linearly increasing temperature (temperature ramp), when cooling, or with a combination of these stages. Figure 2 shows the interconnection between the different modules and components. The Signal Adaptation Electronics module is in charge of conditioning (instrumentation amplifiers) signals coming from sensors at the input of the A/D converter. Moreover, this module is equipped with the circuits needed to actuate the valves with digital signals since they operate with 220 V. Isolation between this voltage and the computing system is required; this is accomplished with optically-coupled circuits. ISBN

23 Figure 2. Acquisition and control diagram. 3. Results The equipment described above was used in several experiments for studying the kinetics of absorption and desorption to form typical ternary hydrides. Figure 3 displays temperature and evolution of the material s pressure when releasing hydrogen according to time. When preset pressure conditions are met, valves automatically open and close between these two values. When hydrogen is released, pressure increases up to a certain value, hydrogen is discharged, pressure decreases, and the cycle is repeated until the sample releases all the hydrogen. Figure 4 illustrates the analytical treatment of measured data. Figure 3. Temperature according to time. Sample desorption. Pressure variation according to time. ISBN

24 Figure 4. Desorption data treatment. 4. Conclusions This paper describes the development and implementation of a piece of equipment for studying hydrogen absorption and desorption in metals. Having used commercially available components, the importance of this proposal lies in its low cost. The design complies with the requirements specified by a research group from the IFLP (Instituto de Física de La Plata [La Plata Physics Institute] - CONICET [for its Spanish acronym, National Council of Scientific and Tehnical Research]), Departamento de Física, Facultad de Ciencias Exactas, UNLP [Physics Department, Faculty of Exact Sciences, National University of La Plata]) that is part of the project Materiales nanoestructurados de aplicación en energías alternativas: síntesis, caracterización y modelado [ Nanostructured materials applicable to alternative energies: synthesis, characterization and modeling ]. The design currently in operation went through several stages: from the development and implementation of the signal adaptation module, to the software that controls and automates the experiment, up to the present situation with variations from the original experiments: constant temperature test, with (linear) increase, acquisition during cooling and gas flow measurement and control. 5. References [1] Optimización de un hidruro complejo para almacenamiento de hidrógeno. Ph.D. thesis. June, 2009 Cardozo, César Luis - Centro Atómico Bariloche [Bariloche Atomic Center]. [2] R. Checchetto, G. Trettel and A. Miotello Sievert-type apparatus for the study of hydrogen storage in solids. Measurement Science and Technology. [3] Conversor A/D- ADQ-12 Microaxial [4] Druck-PDCR 4000 Series High Performance Millivolt Output Pressure Transducers. Motorola - MPX2200 Series On-Chip Temperature Compensated & Calibrated Pressure Sensors. [5] MODBUS Protocol Specification - ISBN

25 Inversión de prioridades: prueba de concepto y análisis de soluciones Raúl Benencia, Luciano Iglesias, Fernando Romero y Fernando G. Tinetti ** Instituto de Investigación en Informática III-LIDI Facultad de Informática, UNLP rbenencia@linti.unlp.edu.ar,li@info.unlp.edu.ar, {fromero,fernando}@lidi.info.unlp.edu.ar, Resumen La planificación de tareas es el punto crucial de un sistema de tiempo real. Dicha función es llevada a cabo por el planificador del sistema operativo, diseñado para poder cumplir con las restricciones temporales de dichas tareas, teniendo en cuenta sus valores de prioridad. Al haber recursos compartidos por estas tareas, se produce el efecto llamado inversión de prioridades. En este trabajo se analiza dicho efecto y se evalúan las soluciones implementadas para este problema en el Sistema Operativo de Tiempo Real GNU/Linux con parche RT-PREEMPT. Keywords: Planificación de tareas de tiempo real, inversión de prioridades, GNU/Linux con parche RT-PREEMPT, Sistemas Operativos de Tiempo Real 1. Introducción Los sistemas de tiempo real requieren ser correctos lógica y temporalmente. Se deben respetar las restricciones de tiempo en la ejecución de las tareas. De acuerdo a la función que realizan, las tareas pueden requerir plazos estrictos o plazos más relajados. Esto conlleva a la necesidad de una planificación basada en prioridades fijas, de manera de asegurar los límites estrictos. Este tipo de planificación es respecto de uno de los recursos compartidos por las diversas tareas, implicadas en la ejecución, la CPU. De tal manera que si un proceso que implementa una tarea de baja prioridad está usando la CPU y otro proceso con una prioridad mayor requiere su uso, está previsto el desalojo del proceso de menor prioridad para asignársela al de mayor prioridad. El resto de los recursos compartidos por las tareas suele planificarse por demanda (FCFS). Al producirse situaciones de bloqueo de estos recursos, que requieren usarse en forma exclusiva (región crítica), puede pasar que el proceso de mayor prioridad quede relegado por uno de menor prioridad. Esta situación se denomina inversión de prioridades [2] y se puede agravar si procesos de prioridad intermedia logran hacerse de la CPU antes de que la tarea de prioridad baja libere el recurso que espera la de ** Investigador CICPBA ISBN

26 2 Inversión de prioridades: prueba de concepto y análisis de soluciones alta prioridad. Con lo cual la duración de la inversión de prioridades puede ser ilimitada y no permitir a la tarea de mayor prioridad cumplir con sus restricciones temporales. Los Sistemas Operativos de Tiempo Real suelen contar con mecanismos para atenuar este problema. En rigor, estos mecanismos no evitan la inversión de prioridades, solo la inversión de prioridades ilimitada. 2. Descripción del problema y soluciones existentes Los Sistemas de Tiempo Real suelen realizar tareas con diferente nivel de urgencia. Si bien todas las tareas pueden tener restricciones temporales para su ejecución, estas restricciones pueden ser estrictas (hard real-time) o menos estrictas (soft real-time) [3]. Esto es manejado por los Sistemas Operativos de Tiempo Real de diferentes maneras. Esto se conoce como planificación de tareas. Uno de los métodos de planificación de tareas se realiza asignando diferentes niveles de prioridad, de tal manera que si se debe incumplir una restricción temporal sea de las tareas con menor nivel de prioridad. A su vez, estas tareas suelen estar implementadas por threads, que se caracterizan por compartir memoria y otros recursos. Esto genera un problema llamado inversión de prioridades, que se describe a continuación: considérese un proceso con prioridad alta, el proceso H, y otro con prioridad baja, el proceso L. Ambos procesos interactúan con el recurso r y, para evitar inconsistencias, deben proteger sus respectivas secciones críticas con un mutex, por ejemplo. Si el proceso H intenta utilizar r mientras L mantiene un lock sobre el mismo, entonces H no podrá continuar su tarea hasta que L no libere el recurso. Hasta aquí se plantea una situación normal. El procedimiento correcto a seguir es asignar el procesador a L para que libere a r lo más pronto posible, para que luego H pueda adquirir el lock sobre el recurso y así continuar su tarea. Sin embargo, el problema de la inversión de prioridades se presenta cuando H espera a que L libere el lock, y mientras L intenta liberar el recurso, el mismo es interrumpido por un proceso de prioridad superior a L pero inferior a H. De esta forma, tanto el proceso L como el proceso H se ven rezagados por el proceso de prioridad media M. En algunos sistemas la inversión de prioridades puede pasar desapercibida puesto que, a pesar de las demoras, las restricciones de tiempo se cumplen y por lo tanto el sistema de tiempo real no falla. Sin embargo, existen numerosas situaciones donde la inversión de prioridades puede causar problemas críticos. Si un proceso de prioridad alta entra en estado de inanición de los recursos que precisa, puede provocar una falla en el sistema que active medidas correctivas, como un watch-dog que reinicie por completo todo el sistema El problema en un caso real: El Rover enviado a Marte Tal vez el caso real más conocido de inversión de prioridades fue el que ocurrió con el rover que se envió al planeta Marte en la misión Mars Pathfinder [4] [5]. La misión Mars Pathfinder fue catalogada como perfecta a los pocos días de su aterrizaje en la superficie marciana, el 4 de julio del año Durante ISBN

27 Inversión de prioridades: prueba de concepto y análisis de soluciones 3 varios días el rover envió cantidades voluminosas de datos, tales como imágenes panorámicas. Sin embargo, luego de pocos días de cumplir con las solicitudes requeridas desde el planeta Tierra, y no mucho después de que el rover comenzara a recolectar datos meteorológicos, el sistema operativo del robot comenzó a reiniciarse continuamente ocasionando severas pérdidas de datos. El problema se encontraba en la administración de las prioridades de VxWorks, el kernel de tiempo real embebido que usaba el Pathfinder. El planificador de VxWorks utilizaba apropiación por prioridades entre los threads. Las tareas en el rover eran ejecutadas como threads. La asignación de prioridades a los mismos se calculaba reflejando la urgencia relativa de dichas tareas. Además, el Pathfinder contenía un bus de información, similar a un área de memoria compartida, utilizado para comunicar información entre los distintos componentes de la nave. El kernel Vx- Works proveía una tarea de alta prioridad dedicada a la administración de este bus, cuya función era mover ciertos tipos de datos desde y hacia el mencionado canal. La recolección de datos meteorológicos se realizaba con poca frecuencia en un thread de baja prioridad, y los datos adquiridos se distribuían utilizando el bus de información. Cuando los datos se distribuían por el bus, se adquiría el lock sobre un mutex, se escribía sobre el bus, y se liberaba el lock. Si una interrupción causaba la apropiación de la CPU mientras el thread de baja prioridad mantenía el bloqueo sobre el bus, y el thread de alta prioridad que administraba dicho bus intentaba adquirir el mismo mutex con el objetivo de recibir estos datos, entonces dicho thread se bloqueaba hasta que el thread de baja prioridad liberase el mencionado mutex. Finalmente, el rover también contenía una tarea dedicada a la comunicación que corría sobre un thread con prioridad media. La mayor parte del tiempo esta combinación de threads funcionaba correctamente. Sin embargo, con muy poca frecuencia ocurría que el thread de comunicaciones, de prioridad media, era interrumpido durante un corto intervalo de tiempo cuando el thread dedicado a la administración del bus, de prioridad alta, era bloqueado para esperar por los datos meteorológicos provistos por el thread de prioridad baja. Cuando se daba esta situación, el thread dedicado a las comunicaciones impedía que el thread de baja prioridad pueda ejecutarse para liberar el mutex. Consecuentemente, el thread de administración del bus era efectivamente bloqueado por una tarea de menor prioridad, provocando de esta forma la inversión de prioridades. Luego de un tiempo prudencial, un watch-dog timer del rover notaba el desperfecto y concluía que algo había dejado de funcionar correctamente, provocando un reinicio total del sistema operativo [6] Soluciones existentes Se han propuesto diversas soluciones (protocolos) para el problema de la inversión de prioridades, acá se mencionan las principales [7]: 1. Herencia de prioridad (Priority inheritance) 2. Techo de prioridad (Priority ceiling) 3. Techo de prioridad inmediato (Inmediate priority ceiling) 4. Enmascaramiento de interrupciones ISBN

28 4 Inversión de prioridades: prueba de concepto y análisis de soluciones 5. Incremento aleatorio 6. Basado en la restauración del recurso (Shadowing) Herencia de prioridad La solución denominada herencia de prioridad propone eliminar la inversión de prioridades elevando la prioridad de un proceso con un lock en un recurso compartido al máximo de las prioridades de los procesos que estén esperando dicho recurso. La idea de este protocolo consiste en que cuando un proceso bloquea indirectamente a procesos de más alta prioridad, la prioridad original es ignorada y ejecuta la sección crítica correspondiente con la prioridad más alta de los procesos que está bloqueando. Por ejemplo, vuélvanse a considerar los procesos L, M y H de prioridad baja, media y alta respectivamente. Suponer que H está bloqueado esperando a que L libere un lock sobre un recurso compartido. El protocolo de herencia de prioridad, entonces, requiere que L ejecute su sección crítica con la prioridad de H. De esta forma, M no podrá apropiarse del procesador cuando L lo tenga en uso. Por lo tanto M, que es un proceso con más prioridad que L, deberá esperar a que L ejecute su sección crítica, ya que L hereda su prioridad de H. Luego, cuando L termina de ejecutar su sección crítica, su prioridad vuelve a la normalidad y el proceso H es despertado. H, que tiene mayor prioridad que M, se apropia del procesador y se ejecuta hasta terminar. Finalmente, cuando H termina su ejecución prosigue el proceso M, y por último L termina su ejecución. El kernel Linux implementa la herencia de prioridades mediante un sencillo mecanismo que se basa en prohibir la apropiación del procesador mientras se esté ejecutando código del kernel protegido por un spinlock. Las desventajas que presenta este método son [8]: 1. Este método puede causar más cambios de contexto que el de techo de prioridad 2. El anidamiento de secciones críticas protegidas por herencia de prioridad puede producir grandes demoras debido a que cada vez que se cambia una prioridad de una tarea debe ejecutarse el planificador 3. El método falla si se mezclan tareas con y sin herencia de prioridad 4. El peor caso de herencia es peor que otras soluciones al problema 5. Según algunos autores, la mayoría de las implementaciones de herencia de prioridad tienden a complicar el código de las secciones críticas, reduciendo finalmente el desempeño del sistema [9] Techo de prioridad La solución denominada techo de prioridad es un protocolo que elimina la inversión de prioridades mediante la asignación predefinida de un techo de prioridad a cada recurso. Cuando un proceso adquiere un recurso compartido, la prioridad de dicho proceso se eleva temporalmente al techo de prioridad del mencionado recurso. El techo de prioridad debe ser más alto que la prioridad de todos los procesos que puedan acceder al recurso compartido. De esta forma, cuando un proceso se esté ejecutando con el techo de prioridad de un recurso, el procesador no podrá ser apropiado por otro proceso que quiera acceder al mismo recurso, puesto que todos tendrán menor prioridad [10]. Las desventajas que tiene este método son: ISBN

29 Inversión de prioridades: prueba de concepto y análisis de soluciones 5 1. Se debe realizar un análisis estático de la aplicación para determinar cuáles serán los techos de prioridad de cada recurso compartido. Para realizar este análisis, todas las tareas que accedan a recursos compartidos deben conocerse de antemano. Esto puede ser difícil, o incluso imposible de determinar en una aplicación compleja [10] 2. La prioridad de los procesos aumenta y disminuye cada vez que se accede a un recurso compartido, aún cuando no haya procesos compitiendo por el mismo 3. Puede dar un bloqueo falso de threads [11] Esta solución fue propuesta por primera vez en 1980, en uno de los primeros papers que describió el problema de la inversión de prioridades [12]. Techo de prioridad inmediato Es un derivado del Protocolo de Techo de Prioridad. En este protocolo, la tarea que accede a un recurso hereda inmediatamente el techo de prioridad del recurso. Este protocolo es mas fácil de implementar y es más eficiente (hay menos cambios de contexto) [13]. Enmascaramiento de interrupciones El enmascaramiento de interrupciones también se puede utilizar para evitar la inversión de prioridades. En este caso, las interrupciones se enmascaran cuando un proceso entra en una sección crítica, y se vuelven a habilitar cuando sale de la misma. De esta forma, la inversión de prioridades no puede ocurrir puesto que todas las secciones críticas se ejecutan sin ser interrumpidas por procesos de mayor prioridad. Para que este mecanismo funcione correctamente, todas las interrupciones deben estar deshabilitadas. Si sólo algunas se enmascaran, entonces la inversión de prioridades podrá ser re-introducida por el mecanismo de gestión de interrupciones del hardware subyacente. Esta solución al problema de inversión de prioridad suele ser encontrada en sistemas embebidos, debido a su confiabilidad, bajo consumo de recursos y sencillez en su implementación. Las desventajas de este método son: 1. Requiere que las secciones críticas sean escasas y cortas, puesto que todo el sistema se ve bloqueado mientras un proceso se encuentra en una de ellas. 2. Mientras las interrupciones estén completamente enmascaradas los fallos de página no podrán ser atendidos [12]. Por este motivo, se desaconseja la implementación de esta solución en sistemas de propósito general. Incremento aleatorio La solución denominada incremento aleatorio propone eliminar la inversión de prioridades mediante el incremento de la prioridad de los procesos de baja prioridad que contengan locks sobre recursos compartidos. La elección del proceso cuya prioridad será incrementada se realiza de forma aleatoria, de ahí el nombre de la técnica. El incremento de la prioridad se mantiene hasta que el lock sea liberado. Esta técnica es utilizada en sistemas operativos Microsoft Windows [14] ISBN

30 6 Inversión de prioridades: prueba de concepto y análisis de soluciones Basado en la restauración del recurso Se basa en la técnica de desalojo de la tarea de menor prioridad que toma el recurso al arribar una tarea de mayor prioridad. Hay dos variantes: mantener un log de lo actuado por el de menor prioridad en el recurso y deshacer los cambios de manera inversa o que la tarea de menor prioridad actúe sobre una copia del recurso, que reemplaza al recurso si la tarea de baja prioridad finaliza antes del arribo de la tarea de mayor prioridad. En caso contrario, la tarea de menor prioridad es desalojada, y el recurso aparece inalterado, como si no se hubiera ejecutado la tarea de menor prioridad. Las demoras las sufre la tarea de menor prioridad en este método. Cabe aclarar que los sistemas operativos de tiempo real, implementan solo algunos de estos métodos: FreeRTOS: es un mini kernel de tiempo real diseñado para sistemas embebidos, preparado para funcionar en diferentes plataformas de microcontroladores. Implementa el protocolo de herencia de prioridad [15]. MarteOS: es un sistema mínimo de tiempo real, basado en ADA, desarrollado por el Grupo de Computadoras y Tiempo Real de la Universidad de Cantabria. Implementa herencia de prioridad y techo de prioridad [16]. QNX : es un micro-kernel de tiempo real de alto desempeño [17]. Implementa la herencia de prioridad. RTAI : Es un sistema basado en Linux que le agrega funcionalidad de tiempo Real. Este sistema es desarrollado por el Politecnico di Milano - Dipartimento di Ingeneria Aerospaziale (DIAPM). Implementa Herencia de Prioridad [18]. RTLinux: las prioridades de las tareas son estáticas manejadas con dos variantes de algoritmo: FIFO o Round Robin [19]. Si bien su creador, Victor Yodaiken dice que RTLinux no soporta la herencia de prioridad por la simple razón de que es incompatible con cualquier sistema de tiempo real confiable [20] existe una extension que da la posibilidad de usar el mecanismo de herencia de prioridad y el techo de prioridad. VxWorks: de la empresa WindRiverSystem, implementa la herencia de prioridad [21]. Linux con parche RT-preempt: implementa herencia de prioridad y techo de prioridad. 3. GNU/Linux con parche RT-PREEMPT GNU/Linux con parche RT-PREEMPT [1] es una modificación realizada al kernel Linux que lo convierte prácticamente en apropiativo, con la excepción de algunas pocas regiones de código pequeñas. Esta modificación permite la ejecución de aplicaciones consideradas hard real-time Caso de prueba Como parte del presente trabajo se desarrolló una aplicación para recrear el fenómeno de la inversión de prioridad en GNU/Linux con parche RT-PREEMPT. ISBN

31 Inversión de prioridades: prueba de concepto y análisis de soluciones 7 Tiene como objetivo evaluar las soluciones de herencia de prioridad y de techo de prioridad implementadas en el kernel. El desarrollo fue realizado en el lenguaje de programación C utilizando semáforos. La aplicación ejecuta tres tareas (threads) de las cuales dos precisan hacer uso de una región crítica en común. Dentro de la región crítica los distintos threads hacen simplemente unas instrucciones que consumen CPU. Cada thread tiene asignada una prioridad, baja (L), media (M) y alta (H). H y L, son los threads que requieren acceder a la región crítica compartida. La aplicación se puede ejecutar de tres maneras diferentes según el algoritmo que utiliza para evitar la inversión de prioridades: inversion: en este modo el programa se ejecuta sin prevenir la inversión de prioridades. inheritance: en este modo el programa evita la inversión de prioridades utilizando el protocolo de herencia de prioridad. ceiling: en este modo el programa evita la inversión de prioridades utilizando el protocolo de techo de prioridad. Sincronización La inversión de prioridades se manifiesta cuando los threads del programa se ejecutan sobre un sistema con un único núcleo. Debido a que este caso de prueba es una simulación, los threads se deben sincronizar para que deliberadamente suceda la inversión de prioridades. Dicha sincronización se lleva a cabo usando tres semáforos a modo de barrera, con el fin de ordenar ejecución y la solicitud de acceso al recurso compartido de los mismos. La sincronización sucede de la siguiente forma, una vez que todos los threads fueron lanzados: Figura 1. Se encuentran los tres threads representados por cada uno de los elipses y las flechas indican el orden y dirección de los avisos para reproducir el fenómeno de la inversión de prioridad. 1. El thread L espera la señal de que H para comenzar sus acciones. Luego de enviar la señal, H se bloquea esperando a que L bloquee el recurso compartido. ISBN

32 8 Inversión de prioridades: prueba de concepto y análisis de soluciones 2. Luego de recibir la señal, L procede a bloquear el recurso compartido. Luego de bloquear el recurso compartido, L envía una señal a H informando este último evento. 3. Cuando H recibe la señal de que el recurso ya está bloqueado, procede a enviar una señal a M. Luego de enviar la correspondiente señal, H procede a intentar adquirir el recurso compartido. 4. Resultados 4.1. Tiempo de ejecución de los threads La aplicación realizada para observar el fenómeno de la inversión de prioridad se ejecutó sobre un kernel Linux 3.2 con el parche PREEMPT RT [1] con un único procesador. La ejecución de inversion provocó la ejecución de los threads en el siguiente orden: H, hasta la solicitud del recurso compartido. M, hasta su finalización. L, hasta que liberó el recurso compartido. H, desde que se hizo del recurso compartido hasta el final. L, hasta su finalización. Efectivamente se produjo la inversión de prioridades. La ejecución de inheritance y de ceiling provocó la ejecución de los threads en el siguiente orden: H, hasta la solicitud del recurso compartido. L, hasta que liberó el recurso compartido. H, desde que se hizo del recurso compartido hasta el final. M, hasta su finalización. L, hasta su finalización. En la tabla 1 pueden apreciarse los tiempos de ejecución de cada uno de los threads. Las entradas indicadas en la tabla no consideran el tiempo transcurrido entre que el thread L libera el recurso y termina su ejecución ya que no es de interés para observar el desempeño general del sistema. Como ya se mencionó estos dos mecanismos (herencia y techo de prioridades) no permiten garantizar las restricciones temporales que eventualmente podría tener la tarea de alta prioridad (H), ya que queda atada a la liberación del recurso compartido por parte de la tarea de baja prioridad (L), pero si evitan que tareas de una prioridad intermedia como M, se ejecuten antes que H Sobrecarga del Sistema Operativo La implementación de cada una de la soluciones sobrecarga al sistema operativo con tareas que debe realizar al momento de adquirir o liberar un recurso. ISBN

33 Inversión de prioridades: prueba de concepto y análisis de soluciones 9 Inversion Inheritance Ceiling L M H Cuadro 1. Tiempos de ejecución de cada uno de los threads, expresados en milisegundos. Por este motivo, no utilizar ninguno de los protocolos que resuelve el problema sería como un caso base sin sobrecarga. La solución de herencia de prioridad en cada solicitud de bloqueo de un recurso compartido, debe analizar si el recurso está o no bloqueado por otro proceso de menor prioridad y de ser así pasarle la prioridad a este para que pueda finalizar lo antes posible. De la misma forma cuando libera el recurso debe analizar si tiene una prioridad heredada para restablecer su prioridad original. Por otro lado, la solución de techo de prioridades debe en cada solicitud de bloqueo determinar la prioridad techo entre todos los procesos que están a la espera del recurso y asignárselo al proceso que tiene el recurso para que este se ejecute inmediatamente. En el momento de la liberación del recurso debe asignar la prioridad techo al proceso de mayor prioridad de entre los que esperan por dicho recurso. Se realizó en GNU/Linux con parche RT-PREEMPT un bloqueo de un semáforo 1. Dicho bloqueo se realizó con la seguridad de que el semáforo no estaba bloqueado previamente, con la intención de hacer un primer análisis de la sobrecarga que cada algoritmo que soluciona la inversión de prioridad conlleva. Con respecto a la opción no impedir la inversión de prioridad, el bloqueo del semáforo con herencia de prioridad llevó un 47 % más de tiempo, mientras que usando el techo de prioridad llevó un 1555 % más de tiempo. 5. Conclusiones y líneas futuras Con respecto a la ejecución de la prueba de concepto, mencionada en 4.1, y como ya se mencionó allí ni la solución por herencia de prioridades ni la solución de techo de prioridades garantizan el determinismo necesario en un sistema hard real-time ya que están ligados a la liberación del recurso compartido por parte de la tarea de baja prioridad. La solución de restauración del recurso si puede garantizar el determinismo necesario, penalizando a las tareas de menor prioridad a que tengan que desechar todo su trabajo con el recurso compartido. Respecto de la sobrecarga del Sistema Operativo (4.2), sólo se analizó la situación con la garantía de que el recurso compartido estaba libre para poder ser bloqueado. El tiempo para el caso de techo de prioridades es mucho más alto que los demás, tal vez debido a la búsqueda inicial de la prioridad techo. Como lineas futuras de investigación queda la opción de ver cuál es la sobrecarga cuando hay otras tareas en ejecución bloqueando el uso del recurso 1 pthread mutex lock ISBN

34 10 Inversión de prioridades: prueba de concepto y análisis de soluciones compartido. También sería de interés analizar la sobrecarga que podría producir una implementación de restauración del recurso. Referencias 1. RTwiki. Page. 2. L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronization. IEEE Trans. Comput., 39(9): , September Alan Burns and Andy Wellings. Sistemas de tiempo real y lenguajes de programación. Addison Wesley, Madrid [etc.], Mars pathfinder The risks digest volume 19: Issue What really happened on mars? authoritative account. Pathfinder/Authoritative Account.html. 7. Tarek Helmy and Syed S. Jafri. Avoidance of priority inversion in real time systems based on resource restoration. IJCSA, 3(1):40 50, Victor Yodaiken. Against priority inheritance, Priority inheritance in the kernel [LWN.net] How to use priority inheritance embedded J. Huang, J.A. Stankovic, K. Ramamritham, and D. Towsley. On using priority inheritance in real-time databases. In Real-Time Systems Symposium, Proceedings., Twelfth, pages , Butler W. Lampson and David D. Redell. Experience with processes and monitors in mesa. Commun. ACM, 23(2): , February Andreu Carminati, Rômulo Silva de Oliveira, and Luís Fernando Friedrich. Implementation and evaluation of the synchronization protocol immediate priority ceiling in PREEMPT-RT linux. Journal of Software, 7(3), March Priority inversion (windows) FreeRTOS - market leading RTOS (real time operating system) for embedded systems supporting 34 microcontroller architectures MaRTE OS home page QNX operating systems, development tools, and professional services for connected embedded systems RTAI - official website RTLinux. March Page Version ID: Rtlinuxpro Victor Yodaiken and Victor Yodaiken. Temporal inventory and realtime synchronization in. 21. Wind river. ISBN

35 Estudio sobre mediciones de Campos Electromagnéticos No Ionizantes Jorge S. García Guibout 1/2. Miguel Méndez Garabetti 1, Antonio Castro Lechtaler 3, Alfredo David Priori (estudiante becado) 1 1 Universidad del Aconcagua, 2 Instituto Tecnológico Universitario, 3 Universidad Tecnológica Nacional (jgarcia@itu.uncu.edu.ar, miguelmendezgarabetti@gmail.com, antonio.castrolechtaler@gmail.com, dalf_p@hotmail.com) Abstract. En la actualidad muchas tecnologías de comunicaciones, medicina y del hogar se basan en la emisión de ondas electromagnéticas (TV, WiFi, telefonía celular, hornos a microondas, etc.). Éstas interactúan con nuestro cuerpo y no se tiene, aun, un acabado conocimiento de esa interacción. Esta situación ha provocado que la sociedad comience a preocuparse por las posibles consecuencias de estas emisiones, pidiendo mayores controles y reglamentaciones. Este trabajo busca conocer, en base al estado actual del conocimiento, la forma correcta de medir estos campos para que se puedan acompañar y justificar las decisiones sobre este tema que pueden llegar a ser necesario tomar en las zonas de influencia del Gran Mendoza y del país todo. Keywords: radiación ionizante, radiación no ionizante, campo eléctrico, campo magnético, ondas electromagnéticas, mediciones. 1 Introducción Los avances tecnológicos han producido cambios trascendentales y muchos de estos cambios son debidos a servicios que emplean ondas electromagnéticas, en especial los servicios inalámbricos. Esta situación lleva a que los seres vivos se vean expuestos constantemente e involuntariamente a los efectos de dichas radiaciones. Éstas pueden resultar perjudiciales para la salud (efectos negativos que pueden provocar riesgos en la salud). Si bien se han realizado numerosas investigaciones para conocer los posibles efectos negativos que este tipo de radiaciones pueden causar en la salud en función a la intensidad con las que las mismas inciden en ellos, algunos de estos son conocidos 1, otros son aun controvertidos 2 por lo que estas investigaciones aún son insuficientes. La Contaminación Electromagnética reconocida por la organización Mundial de la Salud, en primera instancia se enfocó en las antenas de televisión, antenas de radiodifusión, tanto AM y FM, líneas de alta tensión y otras fuentes de RNI [7]. El desplie- 1 Como ser: calentamiento térmico, inducción de corriente eléctrica, etc. 2 Como pueden ser: ciertos tipos de cáncer, alteraciones al sistema nervioso central, leucemia infantil, etc. ISBN

36 gue creciente de la telefonía móvil, según estimó la Unión Internacional de Telecomunicaciones - ITU [9] habría llegado en 2011 a millones de suscriptores. Esta situación generó preocupación e incertidumbre, máxime teniendo en cuenta que este número tan importante de usuarios del servicio impacta directamente en la cantidad de antenas instaladas en ciudades y pueblos. 2 Radiación La radiación podemos definirla como la propagación de energía, sea esta en forma de ondas electromagnéticas o partículas a través del espacio. Toda radiación electromagnética está asociada con la emisión de fotones que son los responsables de la interacción electromagnética. Las características del fotón hacen que claramente podamos observar en la vida diaria fenómenos que son explicados tanto por su naturaleza corpuscular como ondulatoria. El fotón es una partícula sin masa y sin carga eléctrica, lo que hace que viaje en el vacío a la velocidad de la luz. La ausencia de carga eléctrica hace que sea noionizante, es decir que por sí misma no puede alterar el equilibro de carga eléctrica por donde pase. Cada fotón se caracteriza por su energía que es directa y biunívocamente proporcional a su frecuencia, calculando la energía del fotón por la ecuación siguiente: E= h f [Julios] (1) Donde: f es la frecuencia y h es la constante de Planck que es igual a 6,626 x [Js -1 ]. La energía se suele medir en Julios, pero como la energía asociada a cada tipo de radiación electromagnética es débil, se emplea otra unidad de energía llamada ev (electronvoltio). 1eV = 1, J (2) La constante de Planck en dichas unidades será igual a 4, x [ev]. En la naturaleza todas las partículas tienen un comportamiento dual: como partículas y como ondas. Así, algunos fenómenos de la radiación pueden ser entendidos como si fueran ondulaciones, y para otros fenómenos tendremos que concebirlos como si fueran partículas. La realidad es que son ambas cosas, de allí el concepto de dualidad. El comportamiento ondulatorio se manifiesta por medio de campos eléctricos y magnéticos perpendiculares entre sí que oscilan perpendicularmente a la dirección de propagación de la onda. Estas ondas electromagnéticas pueden ser descritas mediante sus parámetros característicos como lo son su frecuencia o longitud de onda y contenido de energía. ISBN

37 En función de la energía que tenga la onda electromagnética la radiación puede ser ionizante (RI) o no ionizante (RNI). Una onda de radio, menor a 30 KHz hasta 1 GHz, poseen una energía desde 1,24x10-10 ev hasta 4,14x10-6 ev, la Luz Ultravioleta, 790 THz, con un energía de 3,3 ev y la Radiación Ionizante, 952 THz en adelante, tienen una energía mayor a 4 MeV. 3 Radiación Ionizante (RI) y NO Ionizante (RNI) La radiación ionizante podemos definirla cómo: las radiaciones que por su frecuencia son capaces de entregar energía a los átomos de las sustancias como para romper los enlaces químicos, desprender un electrón y de esta manera crear un ion, e incluso interactuar con el núcleo del átomo [4]. Cuando un átomo pierde uno de sus electrones se dice que se ioniza, convirtiéndose en un ión o un catión y aún modificar la estructura del núcleo desprendiendo neutrones o protones. Este es el caso de la radiación ultravioleta, los rayos x y los rayos gamma, siendo estos últimos los que pueden interactuar a nivel del núcleo. La radiación ionizante es producida por diversas fuentes como fuentes cósmicas externas (radiación cósmica), materiales radiactivos naturales contenidos en la corteza terrestre, en los ecosistemas y en el interior de los organismos vivos, los que pueden emitir, según sea el elemento, partículas Alfa y Beta, rayos Gamma y radiación exótica debida a materiales radioactivos producidos por el ser humano a partir de 1945 (fuentes bélicas y experimentales, fuentes civiles), aparatos que producen rayos X como energía residual, radiación solar cuya porción ultravioleta C no haya sido detenida por la alta capa de ozono (10 16 a Hz). Este tipo de radiación en su interacción con la materia puede causar daños en tejidos biológicos incluyendo efectos sobre el ADN (ácido desoxirribonucleico: material genético de los seres vivos), por tales motivos las aplicaciones que utilizan este tipo de radiación se utilizan en recintos aislados con importantes cuidados al medioambiente y del personal que opera la tecnología. Por el contrario de la Radiación Ionizante, la Radiación No-Ionizante (RNI) podemos definirla como: las radiaciones que no poseen la suficiente energía, para desprender electrones de los átomos [4]. Este tipo de radiación se extiende desde las frecuencias muy bajas de la luz ultravioleta hasta las frecuencias extremadamente bajas como las del tendido eléctrico (ELF) y los campos magnéticos y eléctricos de naturaleza estática. Su efecto principal es el incremento de la temperatura del material con el que interacciona. Esto es debido a que el fotón al interaccionar con la materia es como si chocara con ella, es decir, su energía pasa a la materia en forma de incremento de Energía Cinética. ISBN

38 La ionización se produce en forma abrupta a partir de un umbral de frecuencia y este umbral es una barrera de energía perfectamente definida, que es diferente en cada material. Si bien este tipo de ondas electromagnéticas no pueden ionizar la materia incidida, si pueden causar otro tipo de efectos sobre la materia. De aquí es que podemos clasificar a los efectos de las RIN en: Efectos térmicos, Efectos no térmicos o biológicos. El cuerpo humano posee mecanismos para regular de forma eficiente su temperatura, pero si la exposición a campos electromagnéticos es demasiado alta, el cuerpo podría no ser capaz de regular tal incremento, por este motivo es que los límites de exposición previenen un incremento de temperatura en el cuerpo humano de 1º C. 4 Tasa de Absorción Específica Ya que los límites de exposición pueden ser establecidos en distintas unidades, para las frecuencias más bajas y hasta varios cientos de MHz, se suele utilizar la intensidad del campo eléctrico expresada en V/m, la intensidad de campo magnético en A/m o la densidad de potencia expresada mw/cm 2 o W/m 2. Pero existe un parámetro dosimétrico ampliamente utilizado el cual se denomina "tasa de absorción específica" o SAR Specific Absorption Rate, el cual se define como: La derivada del aumento de la energía, W, absorbida o disipada en un elemento de masa m, contenida en un elemento de volumen V, cuya densidad es ρ. Puede ser expresado analíticamente como [1]: En la ecuación siguiente se puede observar que el SAR es directamente proporcional al aumento local de la temperatura: (3) (4) donde T es la temperatura en grados Celsius, y Cp es el calor específico del tejido (J/kg C). O sea, que la tasa de absorción específica es la medida de la cantidad de energía de radiofrecuencia que es absorbida por los tejidos en el cuerpo humano y se expresa en W/kg. 5 Efectos en la Salud de las Radiaciones No Ionizantes La preocupación por este nuevo tipo de contaminación se ha acentuado con la aparición de la telefonía móvil, la instalación y permanente funcionamiento de una gran cantidad antenas fijas que operan en el rango de las microondas, y la multiplicación de miles de pequeñas antenas móviles que emiten y reciben estas señales (teléfonos celulares, terminales del sistema, o teléfonos móviles, etc.) [4]. Es por ello que en ISBN

39 diversos ámbitos han continuado las investigaciones respecto a los efectos de ellas tanto en el ambiente como en el cuerpo humano. De acuerdo a estudios realizados, la energía radiante puede ser absorbida por el cuerpo humano mediante tres procesos diferentes: efecto antena, absorción de señal (proceso de absorción relacionado con la constante dieléctrica y el tipo de conductividad del tejido, los cuales son diferentes a distintos valores de frecuencia), absorción biofísica (involucra la absorción resonante por sistemas biológicos como el cerebro o las células). Algunos de los bioefectos y sus mecanismos dependen del rango del espectro de frecuencias de las ondas. Ésta se puede dividir en frecuencia extremadamente baja, que es toda frecuencia menor a 30 KHz, y radiofrecuencia y microondas, que incluye frecuencias hasta 300 GHz, que actúan a nivel de las estructuras de las células que están conformadas por moléculas y átomos cargados que pueden cambiar su orientación y movimiento cuando se encuentran expuestos a una fuerza electromagnética Se ha visto que la radiación de los campos eléctrico y magnético de las frecuencias extremadamente bajas pueden existir separadamente el uno del otro. Normalmente, la discusión sobre los efectos se restringe normalmente al campo magnético que es producido por corrientes alternas o campos variantes en el tiempo, cuya intensidad y dirección cambien de forma regular, ya que los campos eléctricos son fácilmente apantallados [13]. Por otra parte, la exposición a radiaciones de frecuencias extremadamente bajas ocurre a distancias mucho menores que la longitud de onda. Esto tiene importantes implicancias porque bajo tales condiciones se tratan como componentes independientes. La situación es sustancialmente diferente de la que ocurre en la radiación de campos de alta frecuencias, en donde los campos eléctrico y magnético están indisolublemente unidos. Esta es la razón por la que las investigaciones se han centrado en los efectos de un campo o el otro, en frecuencias extremadamente bajas. La interacción del campo electromagnético con sistemas vivos que se ha propuesto teóricamente es la habilidad del campo magnético para estimular corrientes en las membranas de las células y en los fluidos de los tejidos, que circulan en un lazo cerrado que descansa en un plano perpendicular a la dirección del campo magnético. Por tanto, en el interior de un medio biológico se inducen corrientes y campos eléctricos debido al campo magnético. Una posible interacción bajo investigación es que la exposición a campos de frecuencias extremadamente bajas suprime la producción de melatonina, que es una hormona producida por la glándula pineal localizada en una zona profunda del cerebro. La melatonina se produce principalmente por la noche y se libera al cuerpo a través del flujo sanguíneo. Ella llega a casi todas las células del cuerpo humano, estimulando ISBN

40 el sistema inmune, preserva el ADN, las proteínas y los lípidos de daños oxidativos al neutralizar los radicales libre que pueden causar daños estructurales [10]. Además regulan otras actividades como los ciclos menstruales femeninos, el ritmo cardíaco, el sueño, el estado de ánimo y la genética y es esencial para el sistema inmunológico, protegiendo al cuerpo de infecciones y de las células cancerosas. Diversos estudios han encontrado reducción de melatonina en células animales y personas expuestos a campos de frecuencias extremadamente bajas siendo un efecto que depende fuertemente del período de exposición y de la intensidad del campo En cuanto a los efectos biológicos de la RF y microondas se han desarrollado un número significativo de estudios. Estos exploran la posible relación entre la exposición a la radiación de campos RF y microondas y las enfermedades, incluyendo el cáncer; pero todavía deberá pasar un tiempo hasta que se tengan los resultados finales de la mayoría de los estudios. Básicamente, existen dos tipos de efectos biológicos a estas frecuencias Efectos térmicos: ocurren cuando la radiación en cuestión posee suficiente energía como para ocasionar un incremento de temperatura medible. Efectos no térmicos: es una línea de investigación en pleno desarrollo. Podemos decir que se registran efectos biológicos a niveles SAR muy por debajo de los 0,08 W/kg y a densidades de potencia minúsculas de 0,0004µW/cm 2. Es muy importante remarcar que los estándares tanto del ICNIR - International Commission on Non-Ionizing Radiation Protection, la Organización Mundial de la Salud y la Unión Europea se basan, en su mayoría, en efectos térmicos de naturaleza irreversible para exposiciones a corto plazo. 6 Mediciones de las ondas Electromagnéticas La investigación en el área de los bioefectos de la radiación electromagnética ionizante 3 fue anterior a su utilización, lo que permitió reducir los riesgos y por lo tanto aumentar la utilización de dispositivos nucleares generadores de energía, así como también de aquellos derivados de la tecnología de radiación X (medicina, etc.) Los efectos de las radiaciones electromagnéticas no ionizantes de radiofrecuencias son motivo de preocupación, por lo tanto el problema de la dosimetría es muchísimo más complicado en este otro caso 4, que en el de la radiación electromagnética ionizante. Es obvio que los estándares de protección contra la radiación de radiofrecuencias deben expresarse en términos de la intensidad del campo Eléctrico (E), campo Magnético (H) y Densidad de Potencia en el espacio libre (S, como se lo llama en la resolución 3690 de la CNC [16]). 3 Rayos X y gamma. 4 Radiofrecuencias. ISBN

41 El propósito de la medición o prospección de radiación es medir los campos E, H, y S en el ambiente donde el hombre puede estar eventualmente expuesto y comparar esas mediciones con los estándares de niveles permisibles de exposición establecidos Con el fin de poder determinar las condiciones de exposición mínima a las que son expuestas la población y aquellos agentes que trabajan directamente sobre equipamiento emisor de señales electromagnéticas, el Ministerio de Salud y Acción Social de la Nación estableció por medio de la resolución 202/95 [17] los niveles mínimos a los que pueden ser expuestos la población en general y a personas expuestas por su ocupación. En base a esta resolución del Ministerio de Salud y Acción Social de la Nación la Comisión Nacional de Comunicaciones (CNC) emite la Resolución 3690/2004 [16], que abarca a las 269/2002 y la 217 CNC/2003 de la misma repartición, donde se establecen las formas en que deben medirse los niveles de campos eléctricos, magnéticos y/o densidades de potencia en el áreas bajo interés para corroborar lo dictaminado por el Ministerio de Salud y Acción Social de la Nación.. Se presentan en la tabla 1 los valores propuestos por la Resolución 202/95 [17]. Tabla 1: Niveles propuestos por la Resolución 202/95 de MSAS Rango de frecuencia f (MHz) Densidad de Potencia equivalente de onda plana S (mw/cm 2 ) Campo Eléctrico E (V/m) Campo Magnético H (A/m) 0, , /f2 275/f 0,73/f ,2 27,5 0, f/2000 1,375 f/ ,4 - Para la toma de las mediciones, la resolución de la CNC define un campo cercano y un campo lejano, existentes en las proximidades de una antena. En la región del campo lejano, a una distancia mayor que 3λ de la antena, el campo predominante es del tipo onda plana, es decir una distribución localmente uniforme de la intensidad de campo eléctrico y de la intensidad de campo magnético en planos transversales a la dirección de propagación. La región de campo cercano se subdivide a su vez en la región de campo cercano reactivo, que es más próxima al elemento radiante y la región de campo cercano ra- ISBN

42 diante, en la que el campo de radiación predomina sobre el campo reactivo, pero que no es sustancialmente del tipo onda plana y tiene una estructura compleja. El campo Eléctrico se expresará en V/m y el campo Magnético en A/m, la Densidad de Potencia (S) se expresa en mw/cm 2. En una onda plana estos parámetros están relacionados por medio de la impedancia del espacio libre (Z0 = 377 Ω), por lo tanto con la medición de algunos de los campos será suficiente para obtener el resto por medio de la ecuación: 2 E S = = H Z 0 2 Z 0 (5) En el caso de mediciones en el campos cercanos, las componentes de los campos eléctricos (E) y magnéticos (H) son generalmente desconocidas. Por ello, se deberá, en todos los casos, realizar la medición de dichos campos en forma separada. Es necesario introducir las definiciones, que forman parte de de la resolución de la CNC, de Emisión que es la radiación producida por una única fuente de radiofrecuencia, y la de Inmisión que es la radiación resultante del aporte de todas las fuentes de radiofrecuencias cuyos campos están presentes en el lugar. También definimos Potencia Radiada Aparente - PRA como el producto de la potencia suministrada a la antena por la ganancia de antena, en una dada dirección, relativa a un dipolo de media onda y Potencia Isotrópica Radiada Equivalente-PIRE como el producto de la potencia suministrada a una antena por la ganancia de antena, en una dada dirección, relativa a una antena isotrópica. El procedimiento de evaluación para aquellas estaciones cuyas características de radiación impliquen la consideración del campo lejano, la evaluación de los valores de radiaciones no ionizantes (RNI) para el caso de una antena única, las predicciones de densidad de potencia se pueden realizar a partir de las siguientes ecuaciones, que si bien son solamente válidas para los cálculos en el campo lejano de una antena, pueden utilizarse para predecir el peor de los casos, Donde: PRA se considera en W F es la atenuación en veces de la radiación para un cierto ángulo de incidencia en el plano vertical, que si es desconocido toma un valor igual a es un factor de reflexión empírico, que tiene en cuenta que se puedan adicionar campos reflejados en fase. r es la distancia desde la antena PRA*1,64*2,56* F S = 2 4* π * r 2 (6) ISBN

43 O por medio de Donde: PIRE se considera en W PIRE *2,56* F S = 2 4* π * r 2 (7) De estas ecuaciones se puede despejar la distancia mínima a la antena, r, con los valores de densidad de potencia establecidos en la tabla 1 sobre límite de exposición poblacional. En el caso que se determine que se superan los valores límites establecidos en la tabla 1, se deberán llevar acabo mediciones según el protocolo que se detalla a continuación. En base a las características del sistema irradiante y la de los emisores se determinaran los puntos de mayor riesgo tanto externos al predio de la antena como internos al mismo. Se deberá tener en cuenta la topología, edificaciones y superficies reflectoras del lugar. La medición se efectuará en los puntos de mayor acceso por parte del público. En sistemas omnidireccionales se deberán seleccionar 16 puntos como mínimo y para sistemas direccionales se deberán adoptar un mínimo de 4 puntos sobre la dirección de máxima propagación, los 12 puntos restantes deberán ubicarse en función de las características del lóbulo de radiación de dicha fuente. Todos estos puntos serán función de la longitud de onda del sistema emisor. El tipo de instrumento establecido en la resolución son equipos de banda ancha que responden uniforme e instantáneamente a un amplio rango de frecuencias y no son sintonizables. Éstos se emplean con sondas de medición de E y H del tipo isotrópico, para una respuesta independiente de la orientación de la sonda. Los mismos son utilizados para la medición de inmisión. También se menciona instrumentos de banda angosta que operan sobre un amplio rango de frecuencias, pero su ancho de banda instantáneo de medición se reduce a anchos de banda estrechos. Este tipo de dispositivos debe sintonizarse a la frecuencia de interés y utilizarse con antenas aptas para los distintos rangos de frecuencia de medición. Son utilizados para la medición de emisión y proporcionan información de la frecuencia bajo análisis. La secuencia de medición establecida indica que en primer término se medirá inmisión. Si los valores obtenidos superaren los máximos permisibles más estrictos dados en la tabla 1, se continuará midiendo la emisión de cada estación. La medición de inmisión tiene por objeto obtener el nivel pico máximo de los campos eléctrico, magnético o de la densidad de potencia, a lo largo de una línea vertical que represente la altura del cuerpo humano en el punto de medición. ISBN

44 Estas mediciones comienzan a 20 cm por encima del suelo hasta una altura de 2 m a una velocidad constante. Si el valor pico máximo de dichas mediciones resulta inferior al 50% de la Máxima Exposición Permitida -MEP más estricta, se registrará como valor de ese punto. Si dicho valor supera el citado 50% de la MEP más estricta, se deberá realizar una medición con promediado temporal de 6 minutos. En caso que los resultados obtenidos en las mediciones de inmisión superen los límites de la tabla 1, se deberá proceder a la medición de emisión a fin de evaluar los aportes individuales de cada una de las fuentes emisoras de radiaciones no ionizantes. Se medirá la intensidad de campo producida por la estación a verificar sobre cada uno de los puntos de medición seleccionados, por medio de instrumentos de banda angosta asociados con antenas de polarización lineal. A tal efecto podrán utilizarse dos métodos alternativos: a) Orientar la antena en tres direcciones ortogonales entre sí (x, y, z) obteniéndose las componentes de campo respectivas. Los valores cuadráticos de intensidad de campo eléctrico y/o magnético se obtendrán de la suma de los cuadrados de las correspondientes componentes de campo ortogonales, como se observa en las siguientes ecuaciones: E = EX + EY H = HX + HY + E H 2 Z 2 Z (8) b) Orientar la antena en la dirección de máxima señal. Este método es también aplicable a una antena de apertura 7 Conclusiones La permanente y rápida evolución de nuevas tecnologías que utilizan campos electromagnéticos para brindar servicios cada vez más útiles y novedosos, no ha permitido que en forma simultánea se hayan realizado acabadamente las investigaciones de los posibles efectos negativos sobre personas y ecosistemas antes de su masificación. De acuerdo con la bibliografía analizada, se está trabajando fuertemente en la investigación en torno a este fenómeno, tanto en nuestro país como así también en el resto del mundo. Es importante poder medir las magnitudes de los campos magnéticos y eléctricos a los que nos vemos expuestos, de manera que la sociedad esté segura que se cumplen las normativas de seguridad de exposición y tener las herramientas para solicitar las correcciones que sean necesarias. Para ello es necesario conocer las especificaciones nacionales y compararlas con regulaciones internacionales para mejorar en la toma de estas mediciones, tratando de replicarlas en el laboratorio, para después poder adaptarlas a nuestras topología, dis- ISBN

45 tribución poblacional, particularidad de nuestra estructura edilicia, entre otras características propias de nuestra región. En este sentido es importante destacar el aporte del Laboratorio de Investigación Aplicada y Desarrollo (LIADE) de la Universidad Nacional de Córdoba en el estadio y difusión de este tema [11,12]. 8 Bibliografía 1. International Commission on Non-Ionizing Radiation Protection: Recomendaciones para limitar la exposición a campos eléctricos, magnéticos y electromagnéticos (hasta 300 GHz): 2. Organización Mundial de la Salud: Campos electromagnéticos y salud pública: radares y salud humana: 3. Mobile Phone Simulations with Human Head and Hand Models; Computer Simulation Technology; 2011 CST AG, Article/Mobile+Phone+Simulations+with+Human+Head+and+Hand+Models, 4. Capparelli M., Mata N., Montenegro R., Aliciardi M.(2008). El ambientalismo II, la Electropolución, Contaminación por antenas de telefonía celular., editorial Ediciones del País. 5. Agencia Internacional sobre Investigación del Cáncer: index.php 6. Organización Mundial de la Salud; 7. IARC classifies radiofrequency electromagnetic fields as possibly carcinogenic to humans, Press Release N 208, 31 de mayo IEEE Std C (Revision of IEEE Std C ). IEEE Recommended Practice for Measurements and Computations of Radio Frequency Electromagnetic Fields With Respect to Human Exposure to Such Fields, 100 khz 300 GHz ITU: Instituto Latinoamericano de la Comunicación Educativa: ra.htm 1 1. Bruni R., Vanilla O., Taborda R., Evaluación de radiación electromagnética de antenas, L.IADE (Laboatorio de Investigación Aplicada y Desarrollo) Universidad Nacional de Córdoba, Bruni R., Vanilla O., Taborda R, Evaluación de radiación electromagnética de fuentes no naturales, L.IADE (Laboatorio de Investigación Aplicada y Desarrollo) Universidad Nacional de Córdoba, Cátedra Radiaciones, Universidad Nacional de Entre Ríos. 1.pdf 1 4. Portela A., Skvarca J., Matute Bravo E., Loureiro A., Prospección de la radiación electromagnética no Ionizante, Vol.I: Manual de estándares de seguridad para la exposición a radiofrecuencias comprendidas entre 100 KHz y 300 GHz, Dirección ISBN

46 Nacional de Calidad Ambiental Secretaria de Salud Ministerio de Salud y Acción Social Portela A., Skvarca J., Matute Bravo E., Loureiro A.,Prospección de la radiación electromagnética no Ionizante, Vol.II: Radiación de radiofrecuencias: Consideraciones biofísicas, biomédicas y criterios para el establecimiento de estándares de exposición Comisión Nacional de Comunicaciones (CNC) (2004). Resolución 3690/2004 (Boletín oficial Nº , 10/11/04) Ministerio de Salud y acción Social de la Nación (1995). Resolución 202/95 (EXP Nº ). ISBN

47 Isolated Spanish Digit Recognition based on Audio-Visual Features Gonzalo D. Sad, Lucas D. Terissi and Juan C. Gómez Lab. for System Dynamics and Signal Processing, Universidad Nacional de Rosario, Argentina CIFASIS-CONICET, Rosario, Argentina {sad, terissi, Abstract. The performance of classical speech recognition techniques based on audio features is degraded in noisy environments. The inclusion of visual features related to mouth movements into the recognition process improves the performance of the system. This paper proposes an isolated word speech recognition system based on audio-visual features. The proposed system combines three classifiers based on audio, visual and audio-visual information, respectively. An audio-visual database composed by the utterances of the digits (in Spanish language) is employed to test the proposed system. The experimental results show a significant improvement on the recognition rates through a wide range of signal-to-noise ratios. Keywords: Speech recognition, audio-visual speech features, Hidden Markov Models 1 Introduction In recent years, significant research efforts have been devoted to the development of Multimodal Human Computer Interfaces (HCIs) that try to imitate the way humans communicate with each other, which is inherently a multimodal process, in the sense that, for the transmission of an idea, not only is important the acoustic signal but also the facial expressions and body gestures [4]. For instance, a significant role in spoken language communication is played by lip reading. This is essential for the hearing-impaired people, and is also important for normal listeners in noisy environments to improve the intelligibility of the speech signal. Audio Visual Speech Recognition (AVSR) is a fundamental task in HCIs, where the acoustic and visual information (mouth movements, facial gestures, etc.) during speech are taken into account. Several strategies have been proposed in the literature for AVSR [7][6], where improvements of the recognition rates are achieved by fusing audio and visual features related to speech. As it is expected, these improvements are more notorious when the audio channel is corrupted by noise, which is a usual situation in speech recognition applications. These strategies usually differ in the way the audio and visual information is extracted and ISBN

48 combined, and the AV-Model employed to represent the audio-visual information. These approaches are usually classified according to the method employed to combine (or fuse) the audio and visual information, viz., feature level fusion, classifier level fusion and decision level fusion [2]. In feature level fusion (early integration), audio and visual features are combined to form a unique audio-visual feature vector, which is then employed for the classification task. This strategy is effective when the combined modalities are correlated, since it can exploit the covariance between the audio and video features. This method requires the audio and visual features to be exactly at the same rate and in synchrony, and usually performs a dimensionality reduction stage, in order to avoid large dimensionality of the resulting feature vectors. In the case of classifier level fusion (intermediate integration), the information is combined within the classifier using separated audio and visual streams, in order to generate a composite classifier to process the individual data streams [5]. This strategy has the advantage of being able to handle possible asynchrony between audio and visual features. In decision level fusion (late integration), independent classifiers are used for each modality and the final decision is computed by the combination of the likelihood scores associated to each classifier [3]. Typically, these scores are fused using a weighting scheme defined based on the reliability of each unimodal stream. This strategy does not require strictly synchronized streams. In this paper an isolated digit recognition system based on audio-visual features is proposed. This system is based on the combination of early and late fusion schemes. In particular, acoustic information is represented by mel-frequency cepstral coefficients, and visual information is represented by coefficients related to mouth shape. The efficiency of the system is evaluated considering noisy conditions in the acoustic channel. The proposed system combines three classifiers based on audio, visual and audio-visual information, respectively, in order to improve the recognition rates through a wide range of signal-to-noise ratios (SNRs). A Spanish audio-visual database is employed to test the proposed system. The experimental results show that a significant improvement is achieved when the visual information is considered. The rest of this paper is organized as follows, the audio, visual and audiovisual features used for each classifier are described in section 2 together with the database used for the experiments. The proposed classifiers and the early integration strategy are analyzed in section 3. A general description of the proposed system using the late fusion scheme is given in section 4. In section 5 experimental results are presented, where the performance of the proposed strategy is analyzed. Finally, some concluding remarks and perspectives for future work are included in section 6. 2 Audiovisual Database and Features In order to evaluate the proposed speech recognition system an audio-visual database was compiled. This database consists of videos of 16 speakers facing ISBN

49 the camera, pronouncing a set of ten words 20 times, in random order. These words correspond to the Spanish utterances of the digits from zero to nine. The videos were recorded at a rate of 60 frames per second with a resolution of pixels, and the audio was recorded at 8 khz synchronized with the video. All the recorded words in the videos were automatically segmented based on the audio signal, by detecting zero-crossings and energy level in a frame wise basis. The audio signal is partitioned in frames with the same rate as the video frame rate (60 frames per seconds). For a given frame t, the first eleven non-dc Mel-Cepstral coefficients are computed and used to compose a vector denoted as a t. In order to take into account the audio-visual co-articulation, the information of t ca preceding and t ca subsequent frames is used to form the audio feature vector at frame t, o at = [ a t tca,...,a t,...,a t+tca ]. Visual features are represented in terms of a simple 3D face model, namely Candide-3 [1]. This 3D face model, depicted in Fig. 1(a), has been widely used in computer graphics, computer vision and model-based image-coding applications. The advantage of using the Candide-3 model is that it is a simple generic 3D face model, adaptable to different real faces, that allows to represent facial movements with a small number of parameters. The method proposed by the present authors in [8] is used to extract visual features related to mouth movements during speech. As it is described in [8], this visual information is related to the generic 3D model and it does not depend on the particular face being tracked, i.e, this method retrieves normalized mouth movements. The mouth shape at each frame t is then used to compute three visual parameters, viz., mouth height (v H ), mouth width (v W ) and area between lips (v A ), as depicted in Fig. 1(b). These three parameters are used to represent the visual information at frame t, denoted as v t. Similarly to the case of acoustic information, t cv preceding and t cv subsequent frames are used to form the visual feature vector at frame t, o vt = [ v t tcv,...,v t,...,v t+tcv ]. For a particular frame t, the audio-visual feature vector is composed by the concatenation of the associated acoustic and visual feature vectors, that is o avt = [o at,o vt ]. (1) 3 Early Integration In most applications the acoustic channel is corrupted by noise, degrading the recognition rates of audio-only speech recognition systems. The proposed system aims to improve the recognition rates in these situations, by fusing audio and visual features. In the presence of noise in the acoustic channel, the efficiency of a classifier based on audio-only information decreases as the SNR decreases. On the other hand, the efficiency of a visual information classifier remains constant, since it does not depends on SNR. However, the use of only visual information is usually not enough to obtain relatively good recognition rates. It has been shown in several works in the literature [4][7][6], that the use of audio-visual ISBN

50 v A v W vh (a) (b) Fig.1. (a) Candide-3 face model. (b) Visual parameters. feature vectors (early integration) improves the recognition rate in the presence of noise in comparison to the audio-only case. In this section, the performances of audio, visual, and audio-visual classifiers are evaluated using audio-visual features extracted from the compiled database, described in section 2. Then, these results are used to derive the proposed late integration strategy described in section 4. Visual classifier. The visual feature vector o vt at frame t is composed by the concatenation of the visual information contained in t cv preceding and t cv subsequent frames (see section 2). Experiments with 0 to 7 frames of coarticulation (t cv ) were carried out. It must be noted that there is no need to carry out these tests considering different SNRs, since the visual features are not affected by the acoustic noise. The results of these experiments are depicted in Fig. 2, using boxplot representation. As it is customary, the top and bottom of each box are the 75th and 25th percentiles of the samples, respectively, the line inside each box is the sample median, and the notches display the variability of the median between samples. These results were computed across all the words in the vocabulary. Audio classifier. Similarly to the case of visual feature vectors, the audio feature vector o at at frame t is composed by the concatenation of the acoustic information contained in t ca preceding and t ca subsequent frames. To select the optimum value of t ca, experiments with 0 to 6 frames of coarticulation were performed. Since the efficiency of the audio classifier depends on the SNR, these experiments were carried out using several SNR levels for two types of noise: additive Gaussian noise and Babble noise. In Fig. 3, the results derived from these experiments are shown, where only the medians for each noise level and coarticulation parameter, are depicted for visual clarity reasons. Audio-Visual classifier. The audio-visual fusion (early integration) proposed in this paper is based on the concatenation of the audio and visual feature vectors associated to each frame t, as stated in (1). Thus, there are two parameters that define the audio-visual vector: t ca and t cv. Modifying these values ISBN

51 55 50 Recognition rate [%] t cv Fig.2. Recognition rate of the visual classifier using different values of t cv. different structures can be obtained. In a similar fashion than for the audio classifier and video classifier, experiments were performed for t ca and t cv ranging from 0 to 5. These tests were carried out considering different SNRs for the cases of Gaussian and Babble noises. Figure 4 shows the recognition rates obtained for the different SNRs and the two considered noises, for three particular audio-visual fusion configurations, namely t ca = 1 and t cv = 5, denoted as A 1 V 5, t ca = 5 and t cv = 5, denoted as A 5 V 5, t ca = 5 and t cv = 1, denoted as A 5 V 1. It can be noted from Fig. 4 that the better performance at low SNRs is obtained for the case of configuration A 1 V 5, while configurations A 5 V 5 and A 5 V 1 present the better performances at high SNRs. The performance of the remaining configurations lies between these curves following the same properties. Considering the results associated to each classifier, depicted in Figures 2, 3 and 4, it can be clearly noted that the audio classifier performs better than the visual one for high SNRs and viceversa. The combination of audio-visual features leads to an improvement of the recognition rates in comparison to the audio-only case. However, for the case of low SNRs, the audio-visual classifier performs worse than the visual one since fused audio-visual features are degraded by the highly corrupted acoustic data. Using different combination of acoustic and visual features, different performances can be obtained. For instance, if the audio-visual features contains more visual than acoustic information, the performance at low SNRs is improved since visual information is more reliable in this case. However, the efficiency at high SNRs is deteriorated, where the acoustic information is more important. Even for cases where a small portion of ISBN

52 Recognition rate [%] CLEAN 40 db 35 db 30 db 25 db 20 db 15 db Recognition rate [%] CLEAN 40 db 35 db 30 db 25 db 20 db 15 db 10 db db 5 db db db db db 0 db 5 db 10 db t ca (a) Babble Noise t ca (b) Gaussian noise Fig.3. Efficiency of the acoustic classifier using different values of t ca and different SNRs, for the cases of considering (a) Babble noise, and (b) Gaussian noise. audio information is considered, a notorious improvement could be obtained for low SNRs, but the efficiency at high SNRs could be worse than for the audio-only case. Thus, there exists a trade-off between performance at low and high SNRs. 4 Late Integration Taking into account the analysis presented in the previous section, the recognition system proposed in this paper combines three different classifiers based on audio, visual and audio-visual information, respectively, aiming at recognizing the input word and maximizing the efficiency over the different SNRs. In the training stage, a combined classifier is trained for each particular word in the vocabulary. Then, given an audio-visual observation sequence associated to the input word to be recognized, denoted as O av, which can be partitioned into acoustic and visual parts, denoted as O a and O v, respectively, the probability (P i ) of the proposed combined classifier corresponding to the i-class is given by P i = P (O a λ a i ) α P (O v λ v i ) β P (O av λ av i ) γ, (2) where P (O a λ a i ), P (O v λ v i ) and P (O av λ av i ) are the probabilities corresponding to the audio (λ a i ), visual (λv i ) and audio-visual (λav i ) classifiers, respectively, and α, β and γ are real coefficients that satisfy the following condition α + β + γ = 1. (3) The visual (λ v ) classifier is more useful at low SNRs (β is predominant), where the acoustic data is highly corrupted by noise, while at medium levels of SNRs, the audio-visual classifier (λ av ) retrieves the better decisions (γ is predominant). For high SNR conditions, an audio classifier (λ a ) is employed (α is predominant). A block diagram representing this computation is depicted in Fig. 5. ISBN

53 Recognition rate [%] A 1V 5 A 5V 5 A 5V 1 Recognition rate [%] A 1V 5 A 5V 5 A 5V CLEAN SNR [db] (a) Babble Noise CLEAN SNR [db] (b) Gaussian noise Fig. 4. Performance of the audio-visual classifier over the SNRs for three different fusion configurations. (a) Babble noise. (b) Gaussian noise. Audio-visual data Feature Extraction Audio Features Visual Features λ a i λ av i λ v i P (O a λ a i ) P av P i X P (O v λ v i ) Fig.5. Schematic representation of the computation of the probability associated to a particular class i for the proposed combined classifier. P av refers to P (O av λ av i ). 5 Experimental Results In this section, the proposed audio-visual speech recognition system is evaluated using the audio-visual database described in section 2. For each experiment reported in this section, 50 round cross-validation was performed, randomly selecting 70% of the database for training and using the remaining 30% for testing. In these experiments the coefficients of the feature vectors were normalized by subtracting the corresponding sample mean and dividing by the corresponding sample variance, computed over the corresponding training set. To evaluate the recognition rates under noisy acoustic conditions, experiments with additive Gaussian noise and Babble noise, with SNRs ranging from -10 db to 40 db, were performed. As it was previously described, the proposed audio-visual speech recognition system combines three classifiers based on audio, visual and audio-visual information, respectively, in order to improve the recognition rates for different SNRs. ISBN

54 These individual classifiers are implemented using left-to-right Hidden Markov Models (HMM) with continuous observations. In order to select the optimum HMM structure, several experiments were performed considering numbers of states in the range from 3 to 7, numbers of Gaussian mixtures from 4 to 11, and full and diagonal covariances matrices. These tests were carried out for the three cases, namely audio, visual and audio-visual features. Based on these experiments, an optimum HMM structure with 4 states, 6 Gaussian mixtures and full covariance matrices was selected for the three different classifiers. 5.1 Classifier selection For the visual classifier, the results depicted in Fig. 2 shown that the higher accuracy was obtained for 5 frames of coarticulation, which corresponds to a visual feature vector o vt composed by 33 parameters. In the time domain, this corresponds to a sliding window of 183 msec approximately. Thus, t cv = 5 was adopted for this classifier. For the audio classifier, it must be noted that the selection of t ca should be done taking into account that the contribution of this classifier to the final decision stage is important at high SNR conditions. For that reason and looking at Fig. 3, t ca = 4 or t ca = 5 or t ca = 6 could be selected. In order to reduce the dimensionality of the resulting audio feature vectors, without significatively affecting the efficiency of the classifier, t ca = 4 was adopted, which corresponds to audio feature vectors composed by 99 parameters. In the time domain, this corresponds to a sliding window of 150 msec. Regarding the selection of the optimal audio-visual classifier configuration to be used at the final decision stage, it must be taken into account that the contribution of this classifier is important at low and middle range SNR conditions, since at high SNR the audio classifier provides more accurate decisions. Thus, from Fig. 4 an adequate configuration for this purpose is the one using t ca = 1 and t cv = 5, i.e., configuration A 1 V Decision level integration As mentioned in section 4, the combination of the probabilities computed from the independent classifiers, is carried out by the weighted multiplication of the individual probabilities, see Eq. (2), where coefficients α, β and γ modify the contribution to the final decision of the audio, visual and audio-visual classifiers, respectively. The values of these coefficients should be modified for the different SNRs, so that the higher contribution at low SNR comes from the visual classifier, at medium SNRs from the audio-visual classifier, and at high SNRs from the audio classifier. Several experiments were performed using different possible combinations of them to achieve the optimum values. The results of these test are depicted in Fig. 6. For both cases of considering Gaussian and Babble noises, it can be seen that the optimum value of α is the lower one at low SNRs, and it increases as the SNR increases, becoming the higher one at clean audio. On ISBN

55 the other hand, the optimum values of coefficient β present an inverse evolution. While for the case of coefficient γ the higher values are at medium SNRs α βγ 0.9 α βγ Value Value CLEAN SNR [db] (a) Babble Noise CLEAN SNR [db] (b) Gaussian noise Fig.6. Optimum values for coefficients α, β and γ over the SNRs. (a) Babble noise. (b) Gaussian noise. In Fig. 7 the obtained recognition rates of the proposed fusing strategy over the SNRs, using the optimum values for the weighting coefficients α, β and γ, are presented. In this figure, the recognition rates corresponding to the audio, visual and audio-visual classifiers are also depicted. It is clear that the proposed objective of improving the recognition rates through the different SNRs has been accomplished. 6 Conclusions Improvements of speech recognition rates by the incorporation of visual data related to the mouth movements and the late integration of different classifiers are presented in this paper. An isolated Spanish digit recognition system based on audio-visual information was developed to test the proposed system. The acoustic information is represented by mel-frequency cepstral coefficients, while the visual information is represented by coefficients related to mouth shape. Three classifiers based on audio, visual and audio-visual information, respectively, are combined in the proposed system in order to improve the recognition rates through a wide range of signal-to-noise ratios. A Spanish audio-visual database was compiled in order to evaluate the efficiency of the system, considering noisy conditions in the acoustic channel. The experimental results show that a significant improvement is achieved when the visual information is considered. It is important to note that, the absolute recognition rates could be further improved by considering well-known strategies usually employed in speech recognition, for instance, using delta mel-cepstral coefficients in the audio features, ISBN

56 Recognition rate [%] λ a λ v λ av Fusion Recognition rate [%] λ a λ v λ av Fusion CLEAN SNR [db] (a) Babble Noise CLEAN SNR [db] (b) Gaussian noise Fig. 7. Recognition rates of the proposed fusing strategy, audio, visual and audio-visual classifiers. including noisy features in the training stage, etc. Work is in progress, where the extension of the proposed system to the case of continuous speech recognition is considered. References 1. Ahlberg, J.: Candide-3 - an updated parameterised face. Tech. rep., Department of Electrical Engineering, Linkping University, Sweden (2001) 2. Dupont, S., Luettin, J.: Audio-visual speech modeling for continuous speech recognition. IEEE Trans. Multimedia 2(3), (Sep 2000) 3. Estellers, V., Gurban, M., Thiran, J.: On dynamic stream weighting for audio-visual speech recognition. IEEE Transactions on Audio, Speech, and Language Processing 20(4), (2012) 4. Jaimes, A., Sebe, N.: Multimodal human-computer interaction: A survey. Comput. Vis. Image Understand 108(1-2), (2007) 5. Nefian, A.V., Liang, L., Pi, X., Xiaoxiang, L., Mao, C., Murphy, K.: A coupled hmm for audio-visual speech recognition. In: International Conference on Acoustics, Speech and Signal Processing (CASSP02). pp (2002) 6. Potamianos, G., Neti, C., Gravier, G., Garg, A., Senior, A.W.: Recent advances in the automatic recognition of audio-visual speech. In: PROC. IEEE. vol. 91, pp (2003) 7. Shivappa, S., Trivedi, M., Rao, B.: Audiovisual information fusion in human computer interfaces and intelligent environments: A survey. Proceedings of the IEEE 98(10), (2010) 8. Terissi, L., Gómez, J.: 3D head pose and facial expression tracking using a single camera. Journal of Universal Computer Science 16(6), (2010) ISBN

57 Determinación de modelos para el análisis del control y estabilidad de sistemas dinámicos Carlos Álvarez Picaza 1, María Inés Pisarello 1, Jorge E. Monzón 1 1 Dpto de Ingeniería. Fac de Ciencias Exactas. Universidad Nacional del Nordeste Corrientes, Argentina cpicaza@gmail.com Abstract. Los modelos aquí presentados analizan las condiciones de control y estabilidad de dos sistemas dinámicos de distinta naturaleza, uno eléctrico y otro biomédico. Los modelos son desarrollados en el espacio de estados, lo que aporta nuevas respuestas al análisis de sistemas. Keywords: espacio de estados, controlabilidad, estabilidad. 1 Introducción La Teoría de Control Clásico describe al sistema dinámico a través de la relación matemática entre la entrada y la salida, o sea su función transferencia, considerando en general a este sistema dinámico como una caja negra. Esto se muestra en la Fig 1, en la cual se observa que a través de la inyección de diferentes tipos de señales a la entrada de la caja negra se obtiene un conjunto de señales a la salida de la misma, lo que nos permite conocer el comportamiento del sistema dinámico y así definir las propiedades de este sistema [1]. Entonces a partir de estos ensayos es posible establecer una relación matemática de la función de transferencia del sistema en cuestión, dado por: y(t) g(t)= u(t) (1) Fig. 1. Modelo general de caja negra ISBN

58 Normalmente los análisis de datos se realizan desde el punto de vista gráfico en el espacio de los tiempos y en el espacio de las frecuencias, mediante la utilización de la función transferencia correspondiente. Lo que permite la Teoría de Control Moderno es el análisis en otro contexto gráfico conocido como espacio de estados, a partir del cual, se puede inferir nueva información [1,2]. Espacio de Estado: Es el espacio n-dimensional cuyos ejes de coordenadas están formados por el eje x 1, eje x 2,, eje x n, donde x 1, x 2,,x n son las variables de estado. Cualquier estado se puede representar como un punto en el espacio de estados. x( t) Ax( t) Bu ( t) Ec. de Estado y( t) Cx( t) Du( t) Ec. de Salida donde A se denomina matriz de estado, B matriz de entrada, C matriz de salida y D matriz de transmisión directa. Fig. 2. Diagrama en bloque del sistema de control en el espacio de estados. El objetivo de este trabajo es determinar el comportamiento de dos sistemas de distinta naturaleza, uno biomédico (sistema cardiovascular) y otro eléctricoelectrónico (turbina eólica) mediante el análisis de sus funciones de transferencia, es decir sus señales de entrada y salida. Para ello diseñamos un modelo de tipo caja negra en el espacio de estados. 2 Métodos Utilizaremos el modelado en el espacio de estados aplicado a señales de una turbina eólica (energías renovables) y de un electrocardiograma (biomédica). ISBN

59 La señal de entrada para un sistema de control no se conoce con anticipación, pero es de naturaleza aleatoria, y la entrada instantánea no puede expresarse en forma analítica. Solo en algunos casos especiales se conoce con anticipación la señal de entrada y se puede expresar en forma analítica o mediante curvas [3]. En el análisis y diseño de sistemas de control, debemos tener una base de comparación del desempeño de algunos. Esta base se configura especificando las señales de entrada de prueba particulares y comparando las respuestas de varios sistemas a estas señales de entrada. Muchos criterios de diseño se basan en tales señales o en la respuesta del sistema a los cambios en las condiciones iniciales (sin señales de prueba). El uso de señales de prueba se justifica porque existe una correlación entre las características de respuesta de un sistema para una señal de entrada de prueba común y la capacidad del sistema de manejar las señales de entrada reales. Señales de prueba típicas. Las señales de prueba que se usan regularmente son funciones escalón, rampa, parábola, impulso, senoidales, etc. Con estas señales de prueba, es posible realizar con facilidad análisis matemáticos y experimentales de sistemas de control, dado que las señales son funciones del tiempo muy simples [3]. 2.1 Aerogenerador: Debido a la complejidad del modelo del generador de inducción, el principio del proceso de auto-excitación se explica con el uso de un circuito RLC debido a que el comportamiento del generador de inducción es similar a un circuito de este tipo [4]. ei e0 Fig. 3. Modelo para representación en el espacio de estados del generador Donde R representa la resistencia equivalente rotórica y estatórica, L los devanados de estator y C, un banco de capacitares reemplazando a la tensión de línea. Para el modelo objeto de tratamiento la función transferencia es Gs () s 2 1 LC E0() s R 1 s Ei () s L LC (2) ISBN

60 Para definir las variables de estado R 1 1 eo. eo. eo. ei (3) L LC LC x e (4) x 1 o 2 e o (5) y las variables de entrada y salida mediante u e i (6) y e x (7) o 1 Matricialmente, queda planteada la siguiente ecuación de estado u x LC L LC x1 y 1 0. x 2. x1 x1. 1 R 1 x 2 2 (8) (9) 1 LC u 2 x 2 x x1 y R L Fig. 4. Diagrama en bloques funcional del aerogenerador representado en el espacio de estados 1 LC 2.2 Pared Cardíaca: En este trabajo modelamos la dinámica cardíaca utilizando un modelo de Windkessel de tres elementos. El modelo fue elaborado en el espacio de estados. Este enfoque nos permite obtener resultados acerca de la estabilidad del sistema [5]. ISBN

61 e i e 0 Fig Modelo Windkessel de 3 elementos El modelo consiste en una conexión paralela de una resistencia y un capacitor. La resistencia Rp representa la resistencia total periférica y el capacitor C representa la compliancia de los vasos. Otro elemento resistivo entre la bomba y la cámara de aire, Rc, simula la resistencia del flujo sanguíneo debido a la válvula aórtica o pulmonar. L es un elemento inercial en paralelo con la resistencia característica, Rc. Con estos arreglos, el modelo cuenta con la inercia de todo el sistema arterial a bajas frecuencias y a altas y medias frecuencias permiten que intervenga la resistencia característica [6]. Generalizando R p = R y R c muy pequeña, para el modelo objeto de tratamiento es 1 E0() s Gs () LC (10) s s Ei () s RC LC obteniendo ( ). ( ). ( ). ( ). (11) RC LC LC 2 s E0 s se0 s E0 s Ei s para definir las variables de estado eo. eo. eo. ei (12) RC LC LC Quedando planteada la siguiente ecuación de estado u x LC RC LC. x1 x x 2 2 y x x 2 (13) (14) ISBN

62 Teniendo en cuenta estos conceptos, el objetivo de este trabajo es aplicar las ecuaciones de estado a los distintos sistemas para el modelado correspondiente y posterior análisis de controlabilidad. Fig. 7. Diagrama en bloques funcional de la pared cardíaca representada en el espacio de estados 3. Resultados y Discusión 31. Aerogenerador De acuerdo a datos de ensayos en cortocircuito realizado a un generador de 5 KVA y considerando el condensador para estabilizar a la salida, se obtiene Tabla 1. Características eléctricas del sistema generador X L (ohm) R (ohm) C (uf) Sigma 1,5 0, Donde las curvas corresponden a la variación de x 1 y la variación de x 2 (variables de estado). 3.2 Pared Cardíaca Tabla 2. Características funcionales del sistema pared cardíaca Señal PS (mmhg) PD (mm Hg) L (PS-PD) C (e-4cm/mm HG) a ,28 57,12 36,16 7,09 Las curvas correspondientes a estos resultados están definidas en las Fig 8 a 11. ISBN

63 3.3 Controlabilidad y Estabilidad La controlabilidad es una de las propiedades cualitativas de los sistemas dinámicos. A grandes rasgos, la controlabilidad estudia la posibilidad de guiar o llevar los estados de un sistema hacia una posición deseada mediante la señal de entrada [6]. Dada una matriz de Controlabilidad genérica 2 n-1 C = éb AB A B... A Bù ê ë ú (15) û Si el rango de C = n Existe una entrada que hace que el sistema pase de cualquier estado inicial al estado final deseado. Señal Aerogenerador: é ù C = ê ë ú û D= , rango = 2 l min = l max = cond ( C )» G ( s) = s s La Fig. 8 muestra el efecto de la condición de control, aplicada al sistema, indicando una disminución del valor de la frecuencia natural del sistema para nuevos valores de entrada (x1c y x2c). De acuerdo a los polos de la nueva función transferencia, el sistema se hace mas amortiguado, lo que conlleva a una mas rápida estabilidad al nivel 0. Señal Pared Cardíaca: é ù C = ê ë ú û 5 D= *10, rango = 2 l min = l max = cond( C )» G s () = 2 s + s + ISBN

64 XIX Congreso Argentino de Ciencias de la Computación CACIC Variables de estado x1 y x2 Variables de Estado x1 y x x1 x1 x1c x1c x2c x2c -6 x2 x2-8 Fig. 8 Respuesta natural del sistema generador incluyendo la condición de control t mseg t m seg Transición con control Transición con Control 1.2 Transición Normal Transición normal x2 0 x x1 0.5 x1 Fig. 9. Espacio de estados - Sistema Aerogenerador. 3D ISBN

65 XIX Congreso Argentino de Ciencias de la Computación CACIC x1c x1c Variables de Estado x1 y x2 Variables de Estado x1 y x x2c x1 x1 0 x2 x x2c T = 1 latido T=1 latido Fig. 10. Respuesta natural del sistema generador incluyendo la condición de control La incorporación de la condición de control, produce en el sistema de estudio un aumento de la frecuencia natural del mismo, haciendo que el sistema alcance su equilibrio en un tiempo menor (hay que tener en cuenta que la frecuencia natural del sistema se encuentra acotada a 1 latido/seg.) Transición normal Transición Normal Transición con Control Transición con control x2 x x1 x1 3 4 Fig. 11. Espacio de estados - sistema pared cardíaca 3D ISBN

66 4. Conclusiones El hecho de que al utilizar la condición de control, ambos sistemas acortan notablemente la trayectoria desde un estado genérico 1 x x 1 hacia el punto estable, es decir, al utilizar estas herramientas de control el sistema gana estabilidad haciendo a cualquier sistema mas controlable y asegurando su convergencia a su estado de equilibrio. Referencias 1. Ogata K.: Ingeniería de control Moderna. 4ta Edición Ed Pearson. ISBN: Kuo B.: Sistemas de Control Automático. 7ma Edición Ed. Prentice Hall Hispanoamericana S.A. ISBN: Rautenberg C., D Attellis C.: Control lineal Avanzado y Control Óptimo. 1era Edición Ed. Argentina-AADECA. ISBN: Henández Sanchez A.M.: Análisis, Modelado y Simulación de la Operación de Sistemas de Generación Eoleoeléctrica Basados en Generadores de Inducción de Tipo Jaula de Ardilla. Centro Nacional de Investigación y desarrollo Tecnológico. Méjico Monzón J.E., Álvarez Picaza C., Pisarello M.I.: A multiple-input multiple-output system for modeling the cardiac dinamycs. In: Proceedings of the 33th Annual International Conference of the IEEE-EMBS Álvarez Picaza C., Pisarello M.I., Monzón J.E.: Modelado del Sistema Cardíaco en el Espacio de Estados aplicando Criterios de Controlabilidad. In: 1er Congreso de Bioingeniería Costa Rica San José de Costa Rica ISBN

67 Selección sub-óptima del espectro asociado a la matriz de afinidad Luciano Lorenti, Lucía Violini, Javier Giacomantone Instituto de Investigación en Informática (III-LIDI), Facultad de Informática - Universidad Nacional de La Plata - Argentina. La Plata, Buenos Aires, Argentina. {llorenti,lviolini,jog}@lidi.info.unlp.edu.ar Resumen. En este artículo se presenta un método de agrupamiento espectral que incorpora un etapa de selección sub-óptima de características. Los métodos de agrupamiento espectral tienden a determinar la estructura subyacente en un conjunto de patrones, donde otros métodos convencionales por la disposición y características particulares de los agrupamiento, no obtienen los resultados esperados. En este trabajo se propone utilizar un método particular de selección de características que tiene como objetivo determinar el mejor conjunto de autovectores de la matriz de afinidad normalizada. La determinación correcta del subconjunto de autovectores más relevantes, puede ser utilizada para mejorar las características de las particiones generadas. El método es evaluado con datos sintéticos simulando estructuras de datos específicas, y en datos reales obtenidos con una cámara de tiempo de vuelo. Palabras clave: Clustering espectral, Selección de características, Visión por Computadora, Robótica. 1 Introducción Una etapa general de un sistema de reconocimiento automático de patrones es la de reducción de dimensión [1][2]. La reducción del número de características puede realizarse en modo supervisado o no supervisado y las técnicas empleadas pueden ser clasificadas como de selección o de extracción de características [3]. En selección de características se definen criterios para elegir el mejor subconjunto de características de un conjunto original [4][5], y en extracción de características se generan nuevas características mediante transformaciones lineales o no lineales del mismo. El problema particular para el cual el sistema es diseñado y el tipo de datos que define los objetos o fenómenos tratados, determinará si se incluirán las dos etapas, una de extracción y una de selección, o solamente una etapa. El diseño de un módulo de selección de características involucra múltiples consideraciones sobre el conjunto de patrones disponibles, como valores atípicos, imputación de valores, tipo de normalización y compromisos en el número óptimo de características, dadas por el fenómeno de pico [6]. Sistemas con restricciones ISBN

68 temporales o donde el número de características es mucho mayor que el número de muestras son alguno de los casos en que se plantea utilizar sistemas de reducción de dimensión. En este trabajo se propone un método en el cual se seleccionan autovectores en el contexto de un método de agrupamiento (clustering) y no como una etapa clásica en el diseño de un sistema de clasificación. Cuando la estructura de los datos no corresponde a regiones convexas, no es lineal o cuando los métodos clásicos de agrupamiento, jerárquicos o particionales, no obtienen resultados satisfactorios, una alternativa son los métodos de agrupamiento espectral (spectral clustering) [7][8][9]. Las técnicas de agrupamiento espectral utilizan los autovectores de la matriz de afinidad, o de matrices derivadas, para generar una partición del conjunto de muestras en agrupamientos disjuntos, que presenten valores altos de la medida de semejanza adoptada para patrones en un mismo conjunto, y bajos para patrones de conjuntos diferentes. En general el valor de los correspondientes autovalores determina un criterio que permite establecer la prioridad de los autovectores, esta no necesariamente genera la mejor partición del espacio muestral. Es posible entonces aplicar técnicas de selección de características para determinar qué combinación de autovectores genera la mejor partición [10][11][12]. En este artículo se propone un método que combina el potencial de los métodos de agrupamiento espectral con un método específico de selección sub-óptima de características [13]. Se presentan resultados experimentales utilizando datos artificiales e imágenes de rango reales. En particular se utiliza una cámara de tiempo de vuelo [14], utilizada en aplicaciones generales de visión por computadora [15] y robótica [16][17]. En la sección 2 se describe el método de selección sub-óptima de búsqueda secuencial flotante hacia adelante adoptado. En la sección 3 se describe método de cortes normalizados y en la sección 4 se presenta el método propuesto. En la sección 5 se muestran resultados experimentales. Finalmente, en la sección 6 se presentan las conclusiones. 2 Selección Sub-óptima de características 2.1 Selección de Características El problema de selección de características consiste en, dado un conjunto Y de D características determinar cuál es el subconjunto X de tamaño d < D que genera la mayor contribución a la discriminación entre clases. Se puede plantear el problema en términos de la optimización de una función criterio J para un subconjunto de tamaño d. J(X) = max J(Z) Z Y, Z =d El método de selección determinará una función criterio y el algoritmo de búsqueda adecuado para el problema analizado. Una vez determinada la función criterio es necesario definir un algoritmo de búsqueda que tenga como objetivo un compromiso entre optimización y complejidad que resulte viable. El método sub-óptimo ISBN

69 adoptado en este artículo es el método de búsqueda secuencial flotante hacia adelante (SFFS - Sequential Forward Floating Selection) [13][18] y la función criterio adoptada basada en matrices dispersas. El método SFFS fue propuesto para evitar el problema de anidamiento que genera el método de búsqueda secuencial hacia adelante (SFS - Sequential Forward Selection) [19]. 2.2 Búsqueda Secuencial Flotante hacia Adelante Dado el conjunto completo de D mediciones Y = {y j j = 1,..., D}, seleccionar k características, para formar el conjunto X k = {x j j = 1,..., k, x j Y }, que optimice la función criterio J(X k ) correspondiente. Inicialización: X 0 := Ø; k := 0 en la práctica se puede comenzar con k = 2 por aplicar SFS dos veces. Paso 1 (Inclusión): x + := arg max J(X k + x) x Y X k x + es la característica más significativa con respecto a X k. X k+1 := X k + x + ; k := k + 1 Paso 2 (Exclusión Condicional): x := arg max x X k J(X k x) x es la característica menos significativa en X k. if J(X k {x }) > J(X k 1 ) then X k 1 := X k x ; k := k 1 ir a Paso 2 else ir a Paso 1 Terminación: Parar cuando k es igual al número de características requerido 2.3 Medida de Semejanza entre clases Debido al uso recursivo de la función criterio, se propone utilizar la siguiente medida de separación entre clases basada en matrices dispersas. J = tr{s 1 w S m } donde S w = M i=1 P i Σ i y S m = E[(x µ 0 )(x µ 0 ) T ] siendo M el número de clases y P i la probabilidad a priori de cada clase. ISBN

70 3 Agrupamiento Espectral El algoritmo de cortes normalizados propuesto por Shi y Malik [20] modela la segmentación de imágenes como un problema de partición de un grafo. Un grafo G=(V,E) está formado por un conjunto de vértices V y un conjunto de aristas E que relacionan elementos de V. Con el objetivo de construir grafos a partir de imágenes, los vértices son generados a partir de los pixeles que la constituyen. El conjunto de las aristas E está formado por elementos que denotan la semejanza entre los pixeles. Dado un grafo pesado no dirigido G = (V, E), donde V son los nodos y E son las aristas. Sea A,B una partición de un grafo: A B = V, A B =. La semejanza entre dos grupos es llamada cut cut(a, B) = w(i, j) i A,j B donde w(i, j) es el peso de la arista que conecta el vértice i con el vértice j. El criterio propuesto por Shi y Malik utiliza un criterio de semejanza normalizado para evaluar la partición: Ncut(A, B) = cut(a,b) assoc(a,v ) + cut(a,b) assoc(b,v ) Una de las ventajas más importantes para usar el criterio de cortes normalizados es que se puede obtener una buena aproximación de la partición óptima de forma muy eficiente. Sea W ij = w(v i, v j ) la matriz de pesos del grafo y sea D la matriz diagonal de forma que D ii = grado(v i ) = w(v i, v j ) v j V Shi y Malik demostraron que una partición óptima se puede obtener calculando: y = arg min Ncut = arg min y y T (D W )y y T Dy donde y es un vector indicador binario que especifica a qué grupo pertenece cada pixel. Relajando el carácter discreto de y, la ecuación anterior puede ser aproximada resolviendo el sistema de autovalores generalizado: (D W )y = λdy El segundo autovector de este sistema es la solución real del problema discreto de cortes normalizados. 3.1 Ncut simultáneo de k-vías Se define el corte normalizado simultáneo de k-vías que da como resultado k segmentos en una sola iteración de la siguiente forma: Ncut(A 1, A 2,..., A k ) = cut(a1,a1) assoc(a 1,V ) + cut(a2,a2) assoc(a 2,V ) cut(an,an) assoc(a n,v ) ISBN

71 Sea L = (D V ), dado un vector indicador v de un sub-grafo A j tal que resulta que v i = { 1 si i A j assoc(an,v ) 0 si i / A j v T i Lv i = cut(aj,aj) assoc(a j,v ) Sea H la matriz formada por k vectores indicadores puestos en columnas, minimizar Ncut(A 1, A 2,..., A k ) es equivalente a minimizar: min Tr(H T LH) sujeto a H T DH = I A 1,A 2,...A k Se puede hallar eficientemente una aproximación continua de los autovectores discretos que minimizan la traza. Estos son los autovectores correspondientes a los k autovalores más pequeños del sistema de autovalores (D W )u = λdu. 4 Método Propuesto Sea M R n m una matriz que contiene n patrones de m características. 1. Se construye la matriz de afinidad W de forma que W (i, j) = w(v i, v j ) Para imágenes se utiliza: w(v i, v j ) = e F (i) F (j) 2 α I { e X(i) X(j) 2 α X si X(i) X(j) 2 < r 0 c. c. donde X(i) es la locación espacial (x, y) del pixel i y F (i) es el nivel de intensidad del pixel i. 2. Se calcula la matriz diagonal D tal que D(i, i) = grado(v i ) = v j V w(v i, v j ) 3. Sea H la matriz formada por los k autovectores correspondientes a los autovalores más pequeños del sistema de autovalores (D W )u = λdu. 4. Considerando las columnas de H como características y las filas como patrones se aplica el método de selección sub-óptima descripto en la sección Se aplica el algoritmo k-medias sobre el conjunto de patrones utilizando las mejores características. ISBN

72 5 Resultados Experimentales En esta sección se presentan resultados experimentales preliminares del método propuesto aplicado a imágenes simuladas y a imágenes reales. Las evaluaciones comparativas del método han sido realizadas con distintos conjuntos de imágenes de rango, y con diferentes parámetros en la adquisición de las mismas. Las capturas reales fueron obtenidas utilizando la cámara de tiempo de vuelo MESA SwissRanger SR4000 [14] y las imágenes simuladas utilizando el software Blensor [21]. (a) Imagen de rango (b) Clustering espectral (c) Método propuesto Fig. 1. Resultados sobre imagen de rango simulada En la figura 1(a) se muestra una imagen de rango simulada compuesta por cuatro objetos equidistantes del plano focal. La figura 1(b) presenta la segmentación obtenida utilizando las tres primeras columnas de H. En la figura 1(c) se muestra la segmentación obtenida utilizando las columnas de H especificadas en la tabla 1 seleccionadas por el método propuesto. (a) Imagen de rango (b) Clustering espectral (c) Método propuesto Fig. 2. Resultados sobre imagen de rango real La figura 2 muestra imágenes del experimento realizado sobre una imagen real obtenida utilizando la cámara de tiempo de vuelo MESA SR4000. En la figura ISBN

73 2(a) se muestra una imagen de rango correspondiente a dos objetos. La figura 2(b) presenta la segmentación obtenida utilizando clustering espectral. En la figura 2(c) se muestra la segmentación obtenida utilizando el método propuesto. En la tabla 1 se presentan los parámetros utilizados y las columnas de H seleccionadas. (a) Imagen de rango (b) Clustering espectral (c) Método propuesto Fig. 3. Resultados sobre imagen de rango real La figura 3 muestra imágenes del experimento realizado sobre otra imagen real. En la figura 3(a) se muestra una imagen de rango correspondiente a dos objetos con niveles de profundidad similares. La figura 3(b) presenta la segmentación obtenida utilizando clustering espectral. En la figura 3(c) se muestra la segmentación obtenida utilizando el método propuesto. En la tabla 1 se presentan los parámetros utilizados y las columnas de H seleccionadas. Método Columnas de H r α I α X Espectral 1,2, Prueba 1 Propuesto 1,2, Espectral 1,2, Prueba 2 Propuesto 5,7, Espectral 1, Prueba 3 Propuesto 4, Tabla 1. ISBN

74 6 Conclusiones En este artículo se propone utilizar un método de selección de características sub-óptimo embebido en un método de clustering espectral. Los resultados experimentales preliminares sobre datos simulados y reales permiten concluir que la selección adecuada del conjunto de autovectores de la matriz de afinidad mejora la determinación de la estructura subyacente en los patrones de entrada ya sea en datos simulados como reales. El método propuesto muestra potencial para su aplicación en imágenes de rango y de intensidad para problemas que presenten restricciones temporales, si se utilizan cámaras con características similares a la SR4000 de bajo tiempo de adquisición. El método es sensible al ajuste de los principales parámetros del mismo, por lo tanto como parte del trabajo futuro es necesario analizar el comportamiento de los mismos con respecto a los agrupamientos generados. Un segundo aspecto involucra evaluar el mecanismo de selección en otros métodos espectrales y realizar una evaluación comparativa de los resultados para estructuras de agrupamientos complejas. Referencias 1. M.A. Carreira-Perpinan. A review of dimension reduction techniques. Technical report CS-96-09, Department of Computer Science, University of Sheffield, I. K. Fodor. A survey of dimension reduction techniques. Technical report URL-ID , Center for Applied Scientific Computing, Lowrence Livemore Laboratory, P. Narendra, K. Fukunaga. A branch and bound algorithm for feature subset selection. IEEE Transactions on Computers, vol. C-26, no. 9, pp , A. Blum, P. Langley. Selection of relevant features and examples in machine learning. Artificial Intelligence, vol. 97(1-2), pp , M. Kudo, J. Sklansky. Comparison of algorithms that select features for pattern classifiers. Pattern Recognition, vol. 33, pp , R. E. Bellman. Adaptive Control Processes: A Guided Tour. Princeton University Press, J. Shi, J. Malik, Normalized cuts and image segmentation. Proceedings of IEEE Computer Society Conference on Computer Vision and Pattern Recognition, pp P. Perona, W. T. Freeman. A factorization approach to grouping. ECCV, pp A. Y. Ng, M. I. Jordan, Y. Weiss. On Spectral Clustering: Analysis and an algorithm. Advances in Neural Information Processing Systems, vol. 14, T. Xiang, S. Gong. Spectral clustering with eigenvector selection. Pattern Recognition Vol. 41, , F. Zhao, L. Jiao, H. Liu, X. Gao, M. Gong. Spectral clustering with eigenvector selection based on entropy ranking. Neurocomputing Vol. 73, pp , S. A. Toussi, H. S. Yazdi. Feature Selection in Spectral Clustering. International Journal of Signal Processing, Image Processing and Pattern Recognition vol. 4, No. 3, pp , P. Pudil, J. Novovicova, J. Kittler. Floating search methods in feature selection. Pattern Recognition Letters vol. 15, pp , ISBN

75 14. M. Cazorla, D. Viejo, C.Pomares. Study of the SR 4000 camera. XI Workshop de Agentes Físicos, Valencia, A. A. Dorrington, C. D. Kelly, S. H. McClure, A. D. Payne, M. J. Cree. Advantages of 3D Time of Flight Range Imaging Cameras in Machine Vision Applications. 16 th Electronics New Zealand. Dunedin, New Zealand, 95-99, S. May, B. Werner, H. Surmann, K. Pervolz. 3D time-of-flight cameras for mobile robotics. IEEE International Conference on Intelligent Robots and Systems, pp , A. Prusak, O. Melnychuk, H. Roth, I. Schiller, R. Koch. Pose estimation and map building with a Time of Flight camera for robot navigation. International Journal of Intelligence Systems Applications, vol. 5, pp , P. Pudil, F.J. Ferri, J. Novovicova, J. Kittler. Floating Search Methods for Feature Selection with Nonmonotonic Criterion Functions. Proceedings of 12th IAPR Iternational Conference vol. 2, pp , A. W. Whitney. A direct method of nonparametric measurement selection. IEEE Transactions on Computers, vol.20, pp , J. Shi, J. Malik, Normalized Cuts and Image Segmentation. IEEE Transactions on Pattern Analysis and Machine Inteligence, Vol. 22, No. 8, pp , M. Gschwandtner; R. Kwitt; A. Uhl, BlenSor: Blender Sensor Simulation Toolbox. Proceedings of 7th International Symposium In Advances in Visual Computing. ISVC 2011, ISBN

76 Framework para modelado de Transacciones en Sistemas de Bases de Datos de Tiempo Real Carlos E. Buckle, José M. Urriza, Damián P. Barry, Lucas Schorb Depto Informática, Facultad Ingeniería, Universidad Nacional de La Patagonia San Juan Bosco Puerto Madryn, Argentina Int Resumen. En los Sistemas de Bases de Datos de Tiempo Real, se requiere extender el modelo tradicional de transacciones para incorporar restricciones temporales. En este tipo de sistemas, una transacción se debe ejecutar dentro de un intervalo de tiempo específico, predeterminado con anterioridad. Además, se debe garantizar la validez de ciertos datos, cuyo valor caduca con el paso del tiempo. Los conceptos teóricos para modelado de transacciones de tiempo real, han sido desarrollados en varios trabajos del área. En este trabajo, se reúnen y exponen los conceptos principales en lo referido a consistencia temporal de datos y transacciones. Luego, se los incorpora a un framework orientado a objetos que guía y facilita el modelado de transacciones con restricciones de tiempo. El uso del framework se presenta y se verifica aplicándolo sobre un caso de ejemplo. Palabras Clave: Transacciones de Tiempo Real, Consistencia Temporal, Bases de Datos de Tiempo Real, Ingeniería de Software de Tiempo Real, Datos de Tiempo Real. 1 Introducción El procesamiento de transacciones ([1]), es la técnica utilizada para el acceso concurrente, consistente y tolerante a fallas en un Sistema de Bases de Datos (DBS) convencional. Los Sistemas de Tiempo Real (RTS) que manejan datos persistentes sobre un DBS, imponen que el modelo de transacciones sea ampliado para considerar restricciones temporales. Por ejemplo, en sistemas de supervisión y monitoreo de procesos (SCADA), en tableros de comando (Balanced Scorecard), en ambientes de transacciones on-line de compra/venta de acciones bursátiles (Online Stock Trading), etc. Esta aproximación entre las disciplinas de DBS y RTS, ha dado origen a los Sistemas de Bases de Datos de Tiempo Real (RTDBS) ([2, 3]). Los cuales, además de administrar un gran volumen de datos convencionales, deben manejar datos que se encargan de reflejar el estado de elementos variables del ambiente. Estos datos, tienen como característica que su valor envejece, hasta perder vigencia una vez alcanzado su ISBN

77 vencimiento (Datadeadline [4]). Por ese motivo, son identificados en el sistema como datos de tiempo real (RTD Real-Time Data). Mantener correctamente actualizados estos objetos, permite garantizar la consistencia entre el ambiente supervisado y el RTDBS. En este escenario, las transacciones además de garantizar consistencia lógica, deben garantizar consistencia temporal ([2]), dando origen a lo que se denomina transacciones de tiempo real (RTT) (Real-Time Transaction) ([5], [6]). Sobre ellas debe garantizarse: su instante mínimo de inicio (arrival time), su tiempo de respuesta previo al vencimiento (deadline) y la validez de los RTD involucrados. Estas consideraciones, introducen una complejidad adicional al momento de construir aplicaciones. Además de la lógica propia del dominio del problema a resolver, deben atenderse otras cuestiones como: la contabilización de tiempos, la validación de reglas y la planificación de tareas para garantizar la consistencia temporal de datos y transacciones. Surge así la necesidad de contar con herramientas que incorporen estos conceptos, orienten el modelado y aporten la información temporal necesaria para que el planificador del RTS pueda ordenar debidamente la ejecución de las transacciones. En el presente trabajo se presenta un framework orientado a objetos, para el modelado de RTT, como un aporte concreto para los diseñadores de RTDBS. Este documento está organizado de la siguiente manera: en la sección 2 se presentan trabajos anteriores relacionados con el modelado de RTDS. En la sección 3 se presenta un conjunto de definiciones y clasificaciones asociadas con el concepto de RTT. En la sección 4 se presenta el framework desarrollado. En la sección 5 se aplica el framework sobre un caso de estudio. En la sección 6 se elaboran las conclusiones y se plantean los trabajos a futuro. 2 Trabajos previos En el pasado, se han desarrollado una serie de trabajos que apuntan a modelar objetos y transacciones dentro de un RTDBS. Uno de los trabajos más importantes en el modelado orientado a objetos es Real Time Semantic Objects Relationships And Constraints (RTSORAC) ([7]), en el cual se definen tres propiedades básicas de los RTDBS: objetos, relaciones y transacciones de tiempo real. El modelo teórico contempla la mayoría de los requerimientos temporales y permite expresar las diferentes entidades que intervienen en un RTDBS. Sin embargo, es demasiado extenso y genérico como para ser aplicado directamente en el diseño de aplicaciones concretas. No obstante, es utilizado en un conjunto de trabajos posteriores que lo utilizan como base para la definición de perfiles de diseño, como los presentados en [8] y [9]. Dichos trabajos, se enfocan preferentemente a la definición de objetos de tiempo real y no al modelado de transacciones. Tampoco se consideran objetos de cambio discreto ([10]), ni datos derivados (datos calculados). El patrón de diseño presentado en [11], incorpora el modelado de transacciones pero solo de aquellas encargadas de actualizar datos desde sensores. El marco de trabajo (framework) presentado en [12], clasifica aquellas transacciones que actualizan los datos desde ISBN

78 sensores y aquellas que propagan derivaciones de los datos calculados, pero no incluye a las transacciones del usuario que resuelven la lógica de la aplicación. En lo que sigue, se presenta un framework orientado a objetos para el modelado de RTT, en el cual se consideran aspectos ampliados respecto de los trabajos antes mencionados. El framework presentado utiliza el Tipo de Dato Abstracto para Bases de Datos de Tiempo Real RTD ([13]), resultante de un trabajo anterior, el cual se toma como base y permite definir cualquier tipo de atributo de tiempo real encapsulando la validación de consistencia temporal. 3 Gestión de Transacciones con Restricciones Temporales El modelo de RTT, puede definirse como una extensión del modelo tradicional de transacciones ([14]), el cual se resume brevemente a continuación: Un DBS es un conjunto de entidades de datos, que representan información sobre un contexto determinado. El mapeo entre entidades y sus valores, define el estado de la base de datos en un determinado instante. Sobre ella se definen un conjunto de operaciones que permiten recuperar, crear, modificar y eliminar entidades. Estas operaciones provocan la transición de un estado a otro. Una transacción, es un conjunto de operaciones parcialmente ordenadas sobre la base de datos que debe ser ejecutada atómicamente. El orden parcial de las operaciones está dado por un algoritmo. La atomicidad significa que la transacción debe ser ejecutada satisfactoriamente o sino no debe ser ejecutada. Para esto el DBS ofrece dos operaciones: commit, que confirma la finalización satisfactoria de una transacción y rollback, que deshace la ejecución parcial de operaciones realizadas por una transacción que no puede finalizar satisfactoriamente. La transacción pasa de un estado consistente de la base de datos, a un próximo estado consistente. La ejecución de las operaciones ordenadas de una transacción se asume correcta, si se ejecuta en forma aislada. El aislamiento, oculta los cambios parciales que realiza una transacción hasta su finalización. Si la transacción finaliza con commit se garantiza la durabilidad (persistencia) de los resultados en la base de datos. De esta forma se han definido las características ACID (atomicidad, consistencia, aislamiento y durabilidad). Sobre este modelo tradicional de transacciones, se puede incorporar la noción de tiempo real. Una transacción puede conocer el tiempo actual (now) accediendo a una entidad única del sistema llamada reloj (clock). Esta entidad es solo-lectura y toma valores positivos que se incrementan monotónicamente en concordancia con el paso del tiempo. Esto permite establecer intervalos de vigencia sobre los RTD y establecer restricciones temporales sobre las transacciones. Si una transacción no cumple estas restricciones temporales al momento del commit, se debe deshacer (rollback) y si corresponde, volverse a ejecutar (restart). 3.1 Consistencia Temporal de los Datos de Tiempo Real Los RTD reflejan objetos cambiantes del ambiente. Existen dos tipos ([13]): Los RTDBase, los cuales reflejan el estado de un objeto externo y actualizan su valor desde sensores o publicadores y los RTDDerived que son datos derivados, cuyo valor se determina con cálculos sobre un Conjunto-Lectura (Read Set) con otros RTD. ISBN

79 La consistencia temporal de los RTD garantiza: validez temporal: El valor de un RTD se considera válido dentro de un intervalo de validez, VI (validity interval). En el cual el límite inferior (VILB) es el momento en el que se actualiza el valor y el límite superior (VIUB) es el instante en el que el valor pierde vigencia (DataDeadline). Un RTD respeta consistencia temporal absoluta ([10]) en el instante t si VILB ( t) now( t) VIUB ( t). coherencia temporal: Se debe garantizar que los datos calculados se deriven en base a los RTD actualizados en instantes cercanos de tiempo. Por esto, para los RTDDerived se debe garantizar consistencia temporal relativa ([10]) sobre todo su conjunto lectura, es decir, VI x( t) x ReadSet dtr y su VI se calcula como: VILB ( t) Max VILB ( t) x ReadSet VIUB ( t) Min VIUB ( t) x ReadSet y dtr x dtr dtr x dtr Los RTDBase pueden ser continuos (RTDBaseContinuous) ó discretos (RTDBaseDiscrete). Los continuos, son actualizados con muestras periódicas y su VI depende de su edad (tiempo desde su última actualización). El vencimiento del dato se define en base a establecer la edad máxima (maximumage) ([15]) y es posible garantizar la consistencia temporal absoluta, si se considera un período de actualización P maximumage/2 ([4]). Estos conceptos se desarrollaron en la definición del tipo de dato abstracto RTD presentado en [13]. La actualización de los RTDBase puede implementarse utilizando dos políticas: actualización inmediata o a demanda ([16]). La actualización inmediata garantiza que cada cambio en un objeto externo será inmediatamente reflejado en el RTDBase que lo representa. La política de actualización a demanda, significa que el RTDBase será actualizado solo cuando una transacción necesite utilizarlo. La actualización inmediata procura un sistema más predecible, pero genera una carga innecesaria al actualizar valores de RTD que quizás no requiera ninguna transacción. La actualización a demanda soluciona este problema, pero introduce un tiempo de latencia en las transacciones pues deben actualizar los RTDBase antes de utilizarlos. dtr dtr 3.2 Características de las Transacciones de Tiempo Real. Como fue presentado inicialmente, una RTT tiene las restricciones temporales propias: un tiempo mínimo de inicio (starttime) y un tiempo de respuesta anterior al vencimiento (deadline). Además, las RTT están condicionadas por la validez temporal de los RTD involucrados en ella. En un RTDBS se identifican tres clases de RTT: RTT de Actualización de RTDBase (RTTUpdate): Son transacciones de soloescritura sobre un conjunto de RTDBase, llamado Write Set. El sistema debe implementarlas para garantizar la consistencia temporal absoluta de los objetos del Write Set. RTT de Derivación de RTDDerived (RTTDerivation): Son transacciones de lectura sobre un Read Set de RTD y de escritura sobre un Write Set de RTD. El sistema debe implementarlas para garantizar el re-cálculo de datos derivados. ISBN

80 RTT del Usuario (RTTUsrApp): Implementan la lógica de la aplicación de usuario. Son transacciones de solo-lectura sobre un Read Set de RTD, aunque además, utilizan datos convencionales que no tienen restricciones de tiempo real. Dependiendo de la política de actualización de los RTDBase, las RTTUpdate se pueden implementar como transacciones independientes (en actualización inmediata), o como sub-transacciones de una RTTUsrApp (en actualización a demanda). Las transacciones independientes se deben planificar con un período P igual al menor período de los RTDBase en el Write Set. Su DataDeadline se puede calcular como el menor VIUB de dicho conjunto, generalmente como P*2 ([4]). Las RTTDerived pueden ser transacciones independientes o transacciones disparadas (triggered) por una RTTUpdate [16]. Si son independientes se debe planificar con un período P igual al menor período de los RTD en el Read Set. Su DataDeadline es el menor VIUB de todos los RTD incluidos en el Read Set. Cada RTT, independientemente de su clase, puede tener su propio requerimiento de tiempo de respuesta, por ende, debe poder indicarse un tiempo para el vencimiento (timetodeadline) propio de la transacción. Si no se explicita un timetodeadline se puede considerar como máximo un timetodeadline = P (período de la RTT). Para que sea posible la planificación, también es necesario poder estimar el peor caso de tiempo de ejecución de cada transacción (Worst Case Execution Time WCET). 3.3 Planificación de Transacciones Para garantizar las restricciones temporales mencionadas, es necesario que el RTDBS cuente con un planificador de tiempo real (real-time scheduler) que ordene la ejecución concurrente de transacciones. Para que esto sea posible, se debe manejar un conjunto de atributos y medidores de performance de cada RTT. Mínimamente se requiere: arrivaltime: Instante en que la RTT se pone lista para ejecutar. starttime: Instante en que la RTT comienza a ejecutar. WCET. Worst case execution time: Tiempo máximo de ejecución estimado. period: Magnitud del período, para aquellas RTT de ejecución periódica. timetodeadline: lapso de tiempo para el deadline. deadline: vencimiento de la RTT= (arrivaltime + timetodeadline). datadeadline(t): Menor DataDeadline de los RTD del Read Set al instante t. estremaining(t): lapso de ejecución remanente de la RTT al instante t. estcompletiontime(t): Instante estimado de fin en t = (t + estremaining(t)). estslack(t): lapso que se puede retrasar = deadline estcompletiontime(t). En función de algunos de estos parámetros, el planificador de tiempo real debe determinar en cada instante t de planificación la prioridad de la RTT. priority rtt (t): prioridad de la RTT en el instante t. ISBN

81 El algoritmo de planificación, debe garantizar que las RTT del sistema se ejecuten antes de su deadline y que cumplan con las reglas de consistencia temporal. Para esto se debe implementar una política de planificación. Algunas de las posibles son: Rate Monotonic (RM) ([17]): Prioridad basada en la magnitud del período. Earliest-Deadline-First (EDF) ([17]): Prioridad basada en el deadline. Earliest-DataDeadline-First (EDDF) ([4]): Prioridad basada en el datadeadline. Highest-Value-First (HVF) ([18]): Prioridad basada en el la función valor (Fig. 1). Least-Slack-First (LSF)([5]): Prioridad basada en el tiempo disponible (estslack). Shortest-Job-First (SJF): Prioridad basada en el tiempo que resta (estremaining). Estas políticas se pueden mejorar con el agregado de los conceptos de función valor y espera inducida. Estos se describen en los siguientes párrafos. Las RTT pueden tener diferentes niveles de criticidad en su vencimiento. Estos niveles de criticidad, influyen en las decisiones del planificador, el cual puede considerar el concepto de Función Valor introducido por Jensen en [18]. La función valor de una transacción permite medir el valor (ganancia) del sistema si finaliza la transacción en un determinado instante t. Los valores positivos son deseables y los negativos indeseables. Esta función valor presenta una discontinuidad en el vencimiento de la transacción, dependiendo de la cual se identifican vencimientos duros (hard-real-time), blandos (soft-real-time) o firmes (firm-real-time) (Figura 1). Figura 1. Función Valor. Una decisión posible para el sistema, es que si al momento de fin de la RTT se obtiene una función valor negativa se debe deshacer la transacción (rollback). Por otro lado, tampoco es posible finalizar satisfactoriamente una transacción cuyo DataDeadline expira antes que sea posible realizar el commit. Si se puede calcular el parámetro estcompletiontime(t) de una RTT, entonces es posible predecir si se podrá alcanzar el commit antes de que expire el intervalo de validez de los RTD. Si esto no es posible, el planificador puede analizar la posibilidad de retardar la transacción hasta que sus RTD se actualicen nuevamente. A este mecanismo se lo conoce como Espera inducida (Forced Wait)([19]). El planificador debe contemplar: IF datadeadline RTT (t) < estcompletiontime RTT (t): WAIT UNTIL datadeadline RTT (t) ISBN

82 4 Framework RTT para Transacciones de Tiempo Real La construcción de RTDBS requiere considerar los conceptos descriptos en el punto anterior. Resulta útil para los desarrolladores de aplicaciones contar con un marco de trabajo que facilite el diseño de RTT incluyendo atributos, servicios y reglas de validación de consistencia temporal. De esa manera, el desarrollador se puede enfocar más específicamente a la problemática propia del sistema a modelar. En este trabajo se propone el framework RTT. Este es, un modelo orientado a objetos que contempla las características enunciadas para las RTT y que ofrece la información necesaria para que el planificador de tiempo real pueda implementar cualquiera de las políticas de planificación. Figura 2. Framwork RTT Para los datos de tiempo real se ha utilizado un paquete con el tipo de dato abstracto RTD ([13]), el cual caracteriza las diferentes clases de los RTD, encapsula la validación de consistencia temporal de los datos y calcula el Datadeadline de cada objeto. En la Figura 2 se describe el framework RTT en lenguaje UML. ISBN

83 El framework presenta cuatro clases abstractas. Una clase principal Rtt que define atributos y métodos comunes a todas las transacciones de tiempo real y tres subclases que implementan las particularidades de RttUpdate, RttDerivation y RttUsrApp como fue descrito en el punto 3.2. La subclase RttUpdate, permite asociar una lista de RttDerivation que serán disparadas (triggered) en el postcommit(). La subclase RttUsrApp, permite asociar una lista de subtransacciones Rtt que serán ejecutadas al invocar executerttsubtransaction(). Los atributos, métodos y conjuntos (Read Set y Write Set) de cada clase fueron descriptos en 3.3 y se realizan aclaraciones adicionales en notas de la Figura 2. El desarrollador de aplicaciones deberá implementar las RTT del sistema simplemente extendiendo la subclase que corresponda y definiendo la lógica de la transacción dentro del método execute(). Adicionalmente, se puede definir la Función Valor (valuefunction()) de acuerdo a si se desea implementar una RTT de vencimiento duro, firme o blando. Por defecto, Rtt.valueFunction() se define con vencimientos firmes. En la siguiente sección, se muestra el uso del framework RTT aplicándolo sobre un caso de ejemplo. 5 Aplicación en un caso de ejemplo Se desea implementar un monitoreo de salud automatizado sobre una máquina SCADA (Supervisory Control And Data Acquisition). Se realizan diversas mediciones, entre ellas: la carga de trabajo (measureval), la cual se calcula en función de la carga de CPU (cpuworkload), la carga de memoria (memworkload) y la tendencia de carga de los últimos minutos (loadtrend). Las mediciones tomadas se registran en la base de datos cada 20 segundos. Figura 3. Aplicación del Framwork RTT para implementar sistema de mediciones La carga de CPU y de memoria, se obtienen con sensados periódicos cada 4 y 6 segundos respectivamente. La tendencia de carga se obtiene desde la base de datos. ISBN

84 Para implementar este RTDBS se aplica el framework RTT y el diseño de transacciones se muestra en la Figura 3. En el diagrama se definen los RTD necesarios y cuatro RTT encargadas de obtener datos desde los sensores, calcular la medición y grabar en la base de datos. La clase WorkLoadMeasure es la encargada de automatizar la medición. En la Figura 4 se muestra la lógica aplicada: init() : /*Define DTR para sensores */ cpuworkload = new RtdBaseContinuous<Float>(4 secs); memworkload = new RtdBaseContinuous<Float>(6 secs); /*Define DTR derivado. Calcula la medición WorkLoad */ measureval = new RtdDerived<Float>(); measureval.addrtdreadset(cpuworkload); measureval.addrtdreadset(memworkload); /* Define transacción de Cálculo de derivaciones */ derivetrans = new DeriveWorkLoad(pWCET 0.02 secs, ptdeadline 4 secs); derivetrans.addrtdwriteset(measureval); /* Define transacción de Update de sensores */ updsentrans = new UpdateSensors(pWCET 0.05 secs, ptdeadline 4 secs); updsentrans.addrtdwriteset(cpuworkload); updsentrans.addrtdwriteset(memworkload); updsentrans.addrtttriggeredderivation(derivetrans); /* Tendencia de carga con dato de sensado discreto */ loadtrend = new RtdBaseDiscrete<Float>(); /* Define transacción de Update de sensado discreto */ updldtrans = new UpdateLoadTrend(pWCET 0.1 secs, ptdeadline 4 secs); updldtrans.addrtdwriteset(loadtrend); /* Define transacción de Grabar Medición */ savetrans = new SaveMeasure(pWCET 0.1 secs, ptdeadline 20 secs); savetrans.addrtdreadset(measureval); savetrans.addrttsubtransaction(derivetrans); domeasure() : /* Planifica Update de Sensores en RTT periódica*/ updsentrans.setperiod(updsentrans.calcperiod()); RTTScheduler.dispatch(updsenTrans, _PERIODIC); /* Planifica Registro de Medición en RTT periódica*/ savetrans.setperiod(20 secs.); RTTScheduler.dispatch(saveTrans, _PERIODIC); Figura 4. Métodos de la clase WorkLoadMeasure El planificador de tiempo real RTTScheduler instancia las transacciones en el período indicado por el atributo period de la RTT pasada como parámetro y al llegar el momento de inicio, la ejecuta invocando al método execute(). 6 Conclusiones y Trabajos Futuros El trabajo presenta en detalle los conceptos de consistencia temporal en transacciones de tiempo real, que han sido presentados en diferentes trabajos del área. El objetivo principal fue elaborar una herramienta que guíe y simplifique el diseño de transacciones en un Sistemas de Bases de Datos de Tiempo Real. Consecuentemente, se desarrolló el framework RTT, que es un modelo orientado a objetos que incorpora clasificaciones, atributos y servicios necesarios, para implementar los tres tipos de RTT identificadas en el trabajo. Con esta herramienta, el desarrollador de aplicaciones se puede enfocar específicamente en el problema a resolver y dejar bajo la responsabilidad del framework y del real-time scheduler, lo referido a gestión de las transacciones de tiempo real. Finalmente y a modo de verificación, se aplica el framework RTT en la resolución de un problema concreto. No obstante, algunas cuestiones como control de concurrencia, tolerancia a fallos, ambientes distribuidos, infraestructuras de desarrollo, etc. no han sido consideradas. Estos temas se desarrollarán en futuros trabajos sobre esta temática. ISBN

85 Referencias [1] R. Elmasri and S. Navathe, Fundamentals of Database Systems 5/E, 5/E ed.: Addison- Wesley, [2] K. Ramamritham, "Real Time Databases," International Journal of Distributed and Parallel Databases, vol. 1, pp , [3] B. Purimetla, et al., "Real-Time Databases: Issues and Applications," in. vol. ch.20, ed: in S.Son (ed.) Advances in Real-Time Systems, Prentice Hall, [4] M. Xiong, et al., "Maintaining Temporal Consistency: Issues and Algorithms," in Proceedings of International Workshop on Real-Time Database Systems, 1996, pp [5] R. Abbott and H. Garcia-Molina, "Scheduling Real-Time Transactions: A Performance Evaluation," in Proceedings of the 14th VLDB Conference, [6] J. A. Stankovic, et al., "Misconceptions About Real-Time Databases," IEEE Computer, vol. 32, pp , [7] J. J. Prichard, et al., "RTSORAC: A Real-Time Object-Oriented Database Model," In The 5th International Conference on Database and Expert Systems Applications, pp , [8] L. C. DiPippo and L. Ma, "A UML Package for Specifying Real-Time Objects," Computer Standards & Interfaces vol. 22, pp , [9] N. Idoudi, et al., "Structural Model of Real-Time Databases: An Illustration," in Object Oriented Real-Time Distributed Computing (ISORC), th IEEE International Symposium on, 2008, pp [10] K. Ben, et al., "Maintaining temporal consistency of discrete objects in soft real-time database systems," Computers, IEEE Transactions on, vol. 52, pp , [11] S. Rekhis, et al., "Modeling Real-Time applications with Reusable Design Patterns," International Journal of Advanced Science and Technology, vol. 22, pp , [12] A. Hala, et al., "A General Framework for Modeling Replicated Real-Time Database," International Journal of Electrical and Computer Engineering. Word Academy of Science, Engineering and Technology, pp. 4-8, [13] C. Buckle, et al., "Abstract Data Type for Real-Time Database Systems," in XVII Congreso Argentino de Ciencias de la Computación, UNLP. La Plata, Argentina, [14] Soparkar, et al., Time-Constrained Transaction Management: Real-Time Constraints in Database Transaction Systems: Kluwer Academic Publishers, [15] B. Adelberg, et al., "Applying update streams in a soft real-time database system," Proceedings of the 1995 ACM SIGMOD, vol. 24, pp , [16] Y. Wei, et al., "Maintaining Data Freshness in Distributed Real-Time Databases," presented at the Proceedings of the 16th Euromicro Conference on Real-Time Systems, [17] C. L. Liu and J. W. Layland, "Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment," Journal of the ACM, vol. 20, pp , [18] E. D. Jensen, et al., "A Time-Driven Scheduling Model for Real-Time Operating Systems," Proceedings of Real-Time Systems Symposium, pp , [19] M. Xiong, et al., "Scheduling access to Temporal Data in Real-Time Databases," in Real- Time Database Systems: Issues and Applications, Bestavros, et al., Eds., ed: Kluwer Academic Publishers, 1997, pp ISBN

86 Desarrollo de una Ficha Anestésica Web en Áreas criticas Gustavo Bianco 21, Marcelo Sabalza 1, Daniel Luna 1,Gustavo García Fornari 2, Jorge Garbino 1, Martín Waldhorn 2, Estefania Tarsetti 1 1 Departamento de Informatica en Salud, Hospital Italiano de Buenos Aires, Juan D. Peron 4190, Capital Federal, Argentina 2 Servicio de Anestesia, Hospital Italiano de Buenos Aires, Juan D. Peron 4190, Capital Federal, Argentina gustavo.bianco@hospitalitaliano.com.ar; Abstract. Este trabajo se centra en el diseño e implementación de un sistema de registro anestésico web en tiempo real del cual se genera un documento de relevancia asistencial y legal. La solución abarca un híbrido de una aplicación web integrada en la historia clínica electrónica y una aplicación local que maneja la comunicación con el monitor de signos vitales. Debido a la criticidad del ámbito de trabajo se buscó que pueda funcionar en contingencia, logrando una aplicación robusta y confiable.. Palabras clave: Signos Vitales. Anestesiología. Ficha anestésica. Historia clínica. Informática. Tiempo real. 1 Introducción La ficha o registro anestésico es la documentación escrita y gráfica de lo que sucede durante un procedimiento anestésico. Es un documento que cumple fines médicos, legales, de investigación, docentes, estadísticos/epidemiológicos y de referencia para la facturación. A pesar de la importancia del registro anestésico, este tiene un rol secundario dentro del quirófano, ya que la prioridad del anestesiólogo es atender al paciente [1]. El llenado de este registro en papel es manual en la mayoría de las instituciones y los signos vitales como la frecuencia cardíaca, saturación de oxígeno, concentración de dióxido de carbono en la vía aérea, temperatura y tantos otros tienen que registrarse con una frecuencia mínima de 5 minutos [2]. Se ha demostrado que sin entrenamiento previo y con una inversión de bajo costo, se puede implementar en las salas de operaciones el manejo automático de la información anestésica, teniendo siempre presente que para la justicia, una buena ficha anestésica presupone siempre una buena praxis [2]. ISBN

87 La bibliografía reporta que en Estados Unidos en 1998 apenas el 1% de los departamentos de anestesia utilizaban sistemas de documentación informáticos en la sala de cirugía, y se estima que actualmente menos del 10 % de todos los hospitales cuentan con este tipo de sistemas [3]. Un estudio demostró que el 70% de los incidentes que ocurren durante el proceso de anestesia están relacionados a errores humanos, y algunos de estos incidentes muestran una falla de la comunicación funcional entre el personal médico.[4] La exactitud de la gráfica anestésica tradicional parece reducirse además significativamente en caso de incidentes críticos. Por ejemplo se observó que más del 22% de los valores registrados por 10 anestesiólogos sometidos a un incidente crítico complejo simulado, anotaron valores que discrepaban en más de un 25% de la realidad, e incluso se registraron errores superiores al 100% de la realidad. Otro aspecto importante es la posibilidad de realizar análisis posteriores por ejemplo; Benson y Col. revisaron anestesias para localizar la existencia de episodios de hiper o hipotensión arterial, bradicardia, taquicardia e hipovolemia. Estos fueron recogidos en 911 pacientes (5,7%) de forma manual y en pacientes (18,7%) de modo automatizado [5]. Se investigó desarrollos de software que asisten en la tarea de completar el registro electrónico con captura automática de signos vitales en tiempo real, por ejemplo MV- OR de imdsoft[6], SAFERsleep de la empresa del mismo nombre[7] y CompuRecord de Philips [8]. Se vieron varias alternativas de arquitecturas y diseños de interfaces prestando especial atención a este último punto y a la usabilidad. La mayoría del software comercial que realiza registro anestésico son aplicaciones de escritorio, las que no coinciden con el lenguaje de programación y los criterios de ubicuidad, accesibilidad y alta disponibilidad de las tecnologías de desarrollo del Departamento de Informática en salud del Hospital Italiano de Buenos Aires (HIBA). Esta institución cuenta con un sistema de salud informatizado donde la Historia Clínica Electrónica (HCE) de desarrollo propio es su aplicación central y es el repositorio de la documentación de todo acto médico [9]. La HCE es una aplicación web y se busca que la mayoría de las aplicaciones desarrolladas para interoperar con la misma también lo sean. Siendo el registro anestésico una actividad que se desarrolla en muchos casos dentro de los quirófanos, las aplicaciones web ubicadas en servidores centralizados y dependientes de redes de comunicación fisicamente distribuídas (intranets) entran en conflicto con la normativa para sistemas médicos en áreas críticas (IEC60601), las cuales exigen que los sistemas que allí se utilicen se encuentren aislados de las redes eléctricas y de las redes de datos externas. El desarrollo de la Ficha Anestésica Electrónica (FAE) surge como respuesta a múltiples problemáticas, algunas generales y otras particulares de esta Institución. Entre las generales se puede nombrar: Problemas derivados de registros en papel, se pierden en el traslado, se traspapelan o son ilegibles, esto genera problemas médicos, legales y de facturación. La forma de digitalizarlos es realizando un escaneo (siendo muy complicado y costoso de utilizar lo registrado para estadísticas). Los registros se deben almacenar por ley un mínimo 10 años (SALUD PÚBLICA - Ley ). ISBN

88 Se estima que entre el 10 y 15 % del tiempo del anestesiólogo se utiliza para completar la ficha anestésica convencional, esta distracción implica un alto riesgo para el paciente [3]. Particularmente del HIBA: El creciente número de quirófanos como así también de las cirugías que allí se realizan genera una cantidad creciente de información a almacenar. Dado que el HIBA posee un sistema de Historia Clínica Electrónica, la ficha convencional queda fuera del sistema informático. Se dificulta cualquier tipo de análisis estadístico o de investigación. El HIBA tiene la Iniciativa papel cero. El desarrollo de la FAE busca resolver a largo plazo los problemas anteriormente enunciados como así también incluir toda la información que se registra actualmente en la ficha convencional, automatizando la mayor cantidad de tareas posibles. En este trabajo se describe el desarrollo de una solución de software y hardware para el registro en línea de una ficha anestésica electrónica web con captura automática en tiempo real de signos vitales en áreas críticas, respetando las normativas vigentes y los criterios propios de la institución. 2 Materiales y Métodos El Hospital Italiano es un Hospital Universitario de alta complejidad fundado en 1853, pertenece a una red sanitaria sin fines de lucro que incluye 2 hospitales, 23 centros periféricos ambulatorios y 150 consultorios particulares. En la red trabajan 2500 médicos, 1000 enfermeros y 2500 profesionales del equipo de salud provenientes de otras disciplinas. Con el apoyo de 1500 administrativos, los profesionales atienden consultas ambulatorias y internaciones anuales que se distribuyen en sus 750 camas (200 de cuidado críticos). Desde 1998 el HIBA cuenta con un sistema de información en salud integrado. Su historia clínica electrónica (HCE) es web, desarrollada en Java y es el repositorio de la documentación de todo acto médico. Desde el 2013 el HIBA cuenta con 30 quirófanos donde se desempeñan los anestesiólogos, de los cuales 15 pertenecen al Quirófano Central (QC). Existen normas como la IEC60601 que exigen para la atención segura del paciente que las redes de datos y eléctricas deben permanecer aisladas del entorno externo al quirófano durante la cirugía. En la etapa inicial se aprovechó que los nuevos quirófanos centrales estaban en construcción para poder preparar una infraestructura acorde a las necesidades de la FAE. Se diseñó de tal forma que cada quirófano cuenta con un rack informático propio. Además se planteó que cada quirófano sea una unidad funcional independiente y que la FAE cumpla con los siguientes requerimientos: Tiene que poder seguir funcionando ante la eventual falla de los servidores y/o conexiones externas. ISBN

89 En el caso de perder la conexión con los servidores externos, al restablecerse esta conexión debe sincronizar todo los datos que hayan quedado pendientes de actualizar. Debe considerar un funcionamiento en contingencia. Debe ser ejecutada desde dentro de la historia clínica del paciente. Debe ser Web y en el mismo lenguaje que la HCE (JAVA). 2.1 Hardware Para la primera etapa, en el QC, se diseñó una solución dividida en 2 partes: Dentro del quirófano se ubicó un Monitor Touch de grado médico fijado mediante un brazo metálico articulado a la mesa de anestesia y un soporte porta teclado y mouse. En el rack contiguo se alojó un CPU y la comunicación entre ambos se realiza mediante un bloque modulador/demodulador. Este diseño se justifica en que el CPU no es un equipo de grado médico y por lo cual no puede estar alojado dentro del quirófano. Como la distancia entre el CPU y los dispositivos de interfaz humana es de más de 20 metros fue necesario un bloque que module las señales para transmitirlas entre los dispositivos. Los datos son obtenidos de monitores multiparamétricos Philips modelos MP y MX ubicados en las mesas de anestesia. 2.2 Software Se optó por una arquitectura dividida en tres partes: la interfaz de usuario, la interfaz con la HCE y la interfaz con el monitor de signos vitales. A continuación se pude ver un esquema arquitectura propuesta y de sus interrelaciones (Figura 1). ISBN

90 Figura 1: Diagrama de Arquitectura. La interfaz con el monitor multiparamétrico es un servicio web (webservice) instalado en el IIS del CPU en el rack del quirófano que está físicamente conectado al monitor de Signos Vitales. El webservice fue programado en.net como evolución de una aplicación pre-existente (SVCaptor) de desarrollo propio y utilizada desde hace 3 años de forma rutinaria en las terapias y servicios de emergencia del hospital para el registro automático de signos vitales en la HCE desde los monitores paciente Philips [10]. El protocolo de comunicación subyacente fue implementado sobre la capa de transporte física Ethernet y de comunicación lógica del protocolo UDP/IP en base a la interfaz de exportación de datos que tienen los monitores Philips, serie MP y MX y que se ajusta con bastante fidelidad al protocolo estándar de comunicación en tiempo real ISO/IEEE 11073, En este contexto, el CPU de quirófano será el cliente y el monitor el servidor (Figura 2). ISBN

91 Figura 2: Diagrama del protocolo de comunicación. El monitor se configura para que entregue en tiempo real (una muestra por segundo) los signos vitales que le está ingresando a través de sus sensores. Una vez establecida la conexión con el monitor lo siguiente es recibir y filtrar las tramas Ethernet con los paquetes UDP portadores de los mensajes con la información de los signos vitales, parsear estos mensajes, identificar los signos vitales recibidos y tomar correctamente los valores de cada uno. Como el volumen de información es considerable se tomó la decisión de tomar una muestra por minuto de cada signo vital y almacenarla a disco localmente, dejando la potencialidad de configurar este parámetro a futuro. El web service realiza la interfaz entre la aplicación web y el monitor exponiendo métodos o funciones que le permiten iniciar la conexión, informar signos vitales disponibles, configurar cuales se desean capturar, comenzar la captura e informarlos. La interfaz con la HCE recoge de las bases de datos las cirugías programadas con los datos de los pacientes, de los médicos y ofrece una serie de servicios web llamados desde la interfaz del usuario. También al momento de tener que sincronizar la ficha anestésica electrónica se comunica con estos servicios. Una vez que se firma digitalmente la ficha se ejecutan tareas para integrar la información médica (evoluciones, problemas, prácticas, medicamentos, etc) con la HCE. La interfaz de usuario se basa en una aplicación web HTML utilizando las ventajas de los estándares de HTML5 de caché de aplicaciones HTML y de Filesystem, pudiendo con estos APIs cachear la aplicación y los datos (tantos los de la base de datos como los generados desde la aplicación). Con esta arquitectura logramos que al ejecutarse la aplicación se bajen a cache persistivo del browser los datos necesarios para completar la ficha anestésica electrónica durante el procedimiento anestésico y pudiendo grabar localmente en este cache los datos registrados durante la anestesia, corriendo como una aplicación offline con posibilidades de sincronizar con el server los datos recaudados. Esta arquitectura es especialmente robusta ante la pérdida de conexión o caída de los servicios en los servidores de la institución y toleraría un downtime de 48 horas, ya que este es el tiempo de programación de quirófanos en la institución. En el caso ISBN

92 del que downtime sea mayor o sea un paciente de urgencia la aplicación puede funcionar sin los datos del paciente programado, cargando manualmente los datos relevantes del paciente y el episodio, para que una vez en funcionamiento la conexión con los servidores adjuntar la ficha anestésica electrónica a la historia clínica del paciente. 2.3 Registro convencional vs Electrónico Se revisaron registros anestésicos convencionales en papel, detectando fácilmente sus puntos débiles; son de difícil lectura, dependen de la claridad del anestesiólogo y están acotadas en espacio. Algo que surge a posteriori es el desaprovechamiento de la información, ya que por su poca exactitud y confiabilidad no se utilizan para trabajos de investigación ni de análisis. Finalmente se realizó una observación en quirófano, identificando en qué momentos el anestesiólogo realiza el registro anestésico en papel y el tiempo que este conlleva. A partir de todo esto, los integrantes del equipo trabajaron sobre conceptos de usabilidad, diseñaron prototipos y maquetados de la interfaz táctil para testear casos de uso con los anestesiólogos. Esta instancia permitió incluir en la etapa de diseño y desarrollo a los usuario finales, los anestesiólogos, lo que se esperaba brinde un producto con mayor satisfacción y aceptación. Finalmente se elaboró una maqueta del documento que se genera al terminar la ficha anestésica electrónica y queda adosado a la historia clínica del paciente. De comparar el registro anestésico en papel escaneado y el nuevo documento que se genera la FAE se ve una gran diferencia en lo sencillo y legible que resulta entender lo registrado. ISBN

93 Figura 3: Ficha anestésica convencional. ISBN

94 Figura 4: Captura de la Aplicación ejecutándose. Fi gura 5: Maq ueta del CD A que va a la HCE. A su vez se dise ñaro ISBN