File preview
Cyberphysical System Topics in an Embedded Control Class at the University of Michigan
J. S. Freudenberg
Dept. of Electrical Engineering and Computer Science University of Michigan Ann Arbor, MI 48109-2122, USA Email: jfr@umich.edu
J. A. Cook
Dept. of Electrical Engineering and Computer Science University of Michigan Ann Arbor, MI 48109-2122, USA Email: jeffcook@umich.edu
Abstract—We currently teach a popular class in embedded control systems at the University of Michigan and at ETH Zurich, with total enrollment to date over 1200 students. The course was developed, with NSF support, before the term “cyberphysical system” came into vogue. Nevertheless, many topics relevant to a cyberphysical system curriculum are covered in the lectures and laboratory exercises. These include networked control, hybrid dynamical systems, human computer interaction, and modelbased software development. In this paper, we describe the class, its motivation in a request from an automotive OEM, and the associated embedded control laboratory. We close with a discussion of the research conducted in the laboratory, and the synergy between this research and the instructional mission of the lab.
I. I NTRODUCTION For many years we have been teaching a popular class in embedded control systems at the University of Michigan (since 2000) and ETH Zurich (since 2008). At the time the course was conceived and developed, the term “cyberphysical system (CPS)” had yet to be coined. Yet many of the topics discussed in the class are relevant to a CPS curriculum. In the present paper, we describe the content of the embedded control class as it is currently taught, and its origins in a request from industry. The paper is an updated version of one presented in 2005 that focused on industry needs for embedded control education [1]; these needs have only grown since that time. The reader will note several CPS topics that are are covered in the class, including networked and distributed control, hybrid dynamical systems, human-computer interaction, and modelbased software development. Responding to a request in 1998 from the local automotive industry, a new class was created at the University of Michigan, EECS 461: Embedded Control Systems [1]. The industry contact1 noted that traditional undergraduate degree programs were ineffective in producing engineers with the skills required to develop the complex embedded control software required in current automobiles. Electrical engineers with knowledge of control algorithm development were completely unfamiliar with how to implement such an algorithm on an embedded microprocessor. Computer engineers familiar with microprocessors had little or no experience with control algorithms.
1 Dr. Kenneth Butts, then working at Ford Motor Company, and currently with Toyota Technical Center.
The lack of a common knowledge base resulted in engineers who found it difficult to collaborate on the multidisciplinary teams required for embedded control software development. At the time, the automotive industry was faced with the daunting task of developing the software that runs on the numerous embedded and networked microprocessors that were being used to control such new features as variable cam timing and electronic throttle. The move to hybrid and electric vehicles, and the introduction of vehicle-to-vehicle and vehicle-toinfrastructure communication to enable such safety features as adaptive cruise control and collision avoidance systems, has only accelerated this trend. For example, it is estimated that a Chevrolet Volt or a typical Ford vehicle contains 10 million lines of code [2], [3], and the automotive sector is often cited as a prime motivator for CPS research [4]. At Michigan, EECS 461 is taught to senior undergraduate students in electrical engineering and computer engineering, and attracts graduate students in civil, mechanical, aerospace, bio-medical and other fields. The class is currently being offered three times a year, and serves up to 72 students each semester, a number limited only by available laboratory facilities. The ETH Zurich version of the class is offered once a year as a short course to 33 mechanical engineering graduate students. It is one of the challenges of EECS 461 to provide students with such a wide range of academic backgrounds with the knowledge and skills required to work effectively and immediately on embedded control software development. Skills addressed by this class within a model-based embedded control software design paradigm include: modeling and analysis of hybrid-dynamical systems; design of control and signal processing algorithms including frequency response, sampling and aliasing; an understanding of computer hardware including issues of interfacing, memory, and timing; computer software, emphasizing multitasking, numerical methods and real-time computation; sensors and actuators; and distributed control over networks The course employs a Freescale MPC5553 microcontroller and a single-axis haptic interface – the one used at ETH Zurich is shown in Figure 1. As shown in Figure 2, the haptic interface allows a human user to interact, through the sense of touch, with a virtual reality algorithm implemented on a microprocessor. The overall system depicted in Figure 2
The remainder of this paper is outlined as follows. In Section II we describe the MPC5553 microcontroller and haptic interface; Section III describes the laboratory exercises and topics covered in the course, including the final project; Section IV discusses some of the research being carried out in the embedded control systems laboratory. Many of the Michigan course materials are available on the website [6]. Information about the class can be found in the article [7] and webinar [8]. II. E MBEDDED C ONTROL S YSTEMS L ABORATORY The laboratory consists of five major components: an embedded microprocessor, a software development environment, a force-feedback haptic interface, the CAN network that connects the individual processors, and the MATLAB based environment for automatic code generation. The microprocessor used in the EECS 461 laboratory is the MPC5553, the current generation Freescale microcontroller originally developed for automotive powertrain control, but now widely applied across many industries. The 132 MHz 32-bit PowerPC controller2 is able to process a large number of inputs and outputs. For example, the microcontroller incorporates two programmable enhanced Time Processing Units (eTPUs) that are separate processors used to handle I/O that would otherwise require either a separate chip or CPU interrupt service. In the embedded control systems course, this peripheral device is employed along with an optical encoder to determine the position of the haptic wheel using quadrature decoding. The MPC5553 has 1.5 MB of embedded Flash, 64 KB on-chip static RAM, an 8 KB cache and supports 210 selectable-priority interrupt sources. Other peripherals include 2 40-channel ADC, and a 24-channel programmable enhanced Modular Input/Output Subsystem (eMIOS) that can be used for timing, input signal capture and output signal generation such as PWM. In EECS 461, the eMIOS is used to control the haptic interface DC motor via a PWM amplifier in current control mode. The software development environment includes a C compiler and in-circuit debugger. Haptics are used in many application domains, and will be essential in X-by-wire cars, wherein mechanical linkages between the driver and the automobile are replaced by electronics. They do represent a challenging embedded control task, in part because the human haptic sensor, i.e., the sense of touch, has a bandwidth in the range 500–1000 Hz. This implies that the embedded software used to update the virtual reality simulation with which the human interacts must satisfy rather fast timing constraints. The final component of the laboratory is the software used to support model-based control software development. Each workstation is equipped with MATLAB, Simulink, Stateflow, and Simulink Coder (formerly Real-time Workshop), all products of the MathWorks [9]. An OSEK compliant real-time operating system (RTOS) is used to implement multi-rate tasks within a system modeled in Simulink.
2 The MPC5553 microprocessor is operated at 120 MHz in the embedded systems laboratory.
Fig. 1.
Single Axis Haptic Interface used at ETH Zurich.
behavior sensor (taction and kinesthesia) position velocity force sensor (encoder)
Human
actuators (muscles)
Haptic Device CPU
algorithm (virtual environment)
force
actuator (DC motor)
Fig. 2. A physical system (the haptic interface) allows interaction between a cyber system (the virtual world) and a physiological system (the human).
thus has cyber, physical, and even physiological components. Working in teams of two, students implement several virtual environments that can be manipulated through the haptic device, beginning with a virtual wall and finishing with a networked multi-vehicle driving simulator. Essentially every laboratory exercise requires modeling and simulation using tools such as MATLAB, Simulink, and Stateflow, before code is written. Initially, low-level programming is accomplished in handwritten C to develop an understanding of the hardware; ultimately, an extensive driving simulator project is developed using code automatically generated from the system model in Stateflow and Simulink. The teaching laboratory features six workstations each with an MPC5553 development board, a host computer, a custom interface card, and the haptic interface. The workstations are all connected through a Control Area Network (CAN) bus. The haptic interface is essentially a wheel driven by a DC motor in torque control mode using a PWM signal generated by the MPC5553 in response to a change in wheel position as measured by an optical encoder. The specific haptic interface we use at Michigan was developed by Professor Brent Gillespie of the Mechanical Engineering Department. The original version of this device, as described in [5], has now been replaced by a direct drive version similar to that in Figure 1.
III. L ECTURE AND L ABORATORY T OPICS During a fourteen week semester at the University of Michigan, students perform eight 3-hour laboratory exercises and a 4-week final project. There are two 90-minute lectures per week. Each laboratory exercise reinforces a concept taught in lecture, and teaches a different peripheral device on the MPC5553. Furthermore, each lab exercise builds on the previous one, so that throughout the semester students develop a library of software routines that will be reused. The course has been taught once during the abbreviated, seven-week, Spring term at Michigan, and is taught as an intensive (8 hours/day) 2-week block course at ETH Zurich [10]. The fields of embedded control and CPS are highly multidisciplinary, and this fact requires that the lectures and lab exercises cover a broad range of topics, so that students see how they fit together in an application, and begin to appreciate design tradeoffs that must be made across disciplinary boundaries. Initial lecture topics include sampling and quantization, quadrature decoding for position and velocity measurements, frequency response, pulse width modulation, DC motors and motor control. Haptic interfaces are discussed, together with some simple virtual reality environments that students implement in the lab. These include the virtual wall, in which a virtual mechanical stop is implemented to prevent the wheel from rotating past a certain point, and the virtual spring mass system, in which the wheel is made to behave as though it were attached to a virtual wheel through a torsional spring. In the first instance, students will experience an artifact of the digital implementation referred to as “wall chatter,” a high frequency vibration due, in part, to sampling and quantization. In the second case, students will be introduced to real-time numerical algorithms used to implement the virtual dynamic system and understand the tradeoffs among speed, simplicity and numerical stability. Students are required to construct Simulink models of the virtual worlds they create, and to make sure that their algorithms work in simulation before they are allowed to implement them in the lab. In particular, the virtual wall is a simple hybrid dynamical system that the students learn to model using Stateflow. Computing issues covered in lecture include interrupt processing, shared data problems and multitasking, plus concepts from real-time operating systems such as task states and priorities and semaphores. The problems of deadlock and priority inversion are discussed, together with advanced approaches to shared data such as the priority inheritance and priority ceiling protocols. Topics in real time computation include a discussion of rate monotonic analysis and earliest deadline first scheduling. Emphasis is placed upon networked control, as students must implement force feedback algorithms over a CAN bus. A. Laboratory Exercises and Project The eight laboratory exercises start with implementing simple digital inputs and outputs, and extend to automatic code generation and distributed system implementation.
Lab 1, Familiarization and Digital I/O: In the first exercise, students learn to write C for embedded applications and to perform low level bit manipulations needed to access special purpose registers in the memory-mapped processor. In this simple “Hello World” exercise, students read two 4-bit numbers from DIP switches, sum them, and echo the result to LEDs. Lab 2, Fast Quadrature Decoding Using the eTPU: Here, students interface the optical encoder on the haptic wheel to the time processing unit on the microcontroller (using the general purpose I/O learned in the first exercise), and use the quadrature decode function to measure the position of the wheel. Students compute the maximum rate at which the haptic wheel can turn before the count register associated with the eTPU over/underflows and the MPC5553 loses track of position. Lab 3, Analog to Digital Conversion: Students learn to program the eQADC module on the MPC5553, and perform timing analyses to determine how long the conversions take. With this information, students investigate aliasing, and demonstrate the sampling concepts discussed in the lectures. Lab 4, Pulse Width Modulation and Introduction to Simple Virtual Worlds: The DC motors used to provide force feedback are driven by a PWM amplifier that, in turn, is driven by the programmable eMIOS on the MPC5553. In this exercise, students learn to program this module and use it to construct their first example of a virtual reality, the virtual wall described above. To do so, the processor implements a force feedback law stating that if the wheel “penetrates” the virtual wall (i.e., turns past the position of the virtual stop), then a strong restoring force proportional to the penetration distance is applied, effectively a virtual spring. Students are required to work with the conversion factors between wheel angle and encoder counts, and between PWM duty cycle and torque, so that a prescribed penetration corresponds to the software limited maximum motor torque. Lab 5, The Periodic Interrupt Timer and Frequency Analysis of PWM Signals: Simple virtual worlds such as the virtual wall can be implemented in a software loop, and do not require a concept of time, as would be needed for numerical differentiation or integration. More complex worlds do require a time step, and students learn to supply this using one of the interrupt timers on the MPC5553. In this lab they create an interrupt routine that modulates the eMIOS PWM duty cycle by sampling a sine wave. When the resulting signal is passed through a hardware filter and displayed on an oscilloscope, the sine wave is recovered. Students write and measure the execution time of three different interrupt routines to obtain the sine wave samples: by sampling the output of a signal generator, by using the C sine function, and by using a lookup table. This reinforces that three functionally equivalent approaches to the same task can impose very different timing demands upon the processor. Lab 6, Virtual Worlds with Time: Using the interrupt routines developed in the previous lab, virtual worlds that require numerical integration or differentiation can be imple-
mented. In this lab, students program the MPC5553 to simulate the effect of a virtual wheel attached to the physical wheel with a virtual torsional spring. The virtual inertia and spring constant must be chosen so that, in response to a 45◦ step in the physical wheel, the virtual inertia will oscillate at 1 Hz, with a specified maximum torque. Before the students begin writing software to implement the virtual inertia, they are required to develop a Simulink model to verify that their force feedback algorithm, if implemented correctly, will have the desired behavior. Students use forward Euler numerical integration, because it is easier to implement in real time. This, however, results in instability. Students are asked to compute the amount of virtual damping needed to offset the destabilizing effect of the Euler integration, and verify the result in simulation, before testing their code on the haptic wheel. Lab 7, Controller Area Networking: The six workstations in the EECS 461 lab are connected over a CAN network. In this lab students learn to transmit and receive messages over the CAN bus. They first implement a virtual wall over the network, and experience degradation in the quality of the wall they can implement due to networking delay. They then implement a virtual chain of wheels – when one is turned all the wheels in the room also turn using a simple position tracking algorithm. If the position of one wheel is held constant, then the person turning the master wheel experiences an opposing force. Students find this lab challenging because everyone must write code to the same standard to enable communication, and especially because of the complexity of debugging distributed software. Lab 8, Introduction to Autocode Generation: To this point, all the embedded software has been implemented in handwritten C code, although Simulink modeling has been used to verify that the force feedback algorithms have the correct functionality. In this lab, students generate embedded software directly from Simulink and Stateflow diagrams. To do so, they use Simulink Coder from the MathWorks, the Freescale RAppID development system that implements a set of device driver blocks for the MPC5553, and an OSEK compliant RTOS used to specify task priorities and to address shared data issues. Students construct a Simulink model of two virtual wheels with significantly different natural frequencies, thus motivating an implementation in task states executed with different periods and, consequently, different priorities. Project: Students use the knowledge gained in eight laboratory exercises to design and implement a driving simulator using the haptic wheel to steer a mathematical vehicle model along a virtual road. Ultimately, every team’s driving simulator is connected via CAN and simulated on a single road. Students implement an adaptive cruise controller to maintain a preset distance between virtual cars on the road. The project requires about four weeks, and student teams implement their driving simulators entirely in code generated from Simulink and Stateflow models. Stateflow is particularly valuable in describing the three required operating modes: manual, in which the speed of the virtual car is controlled by a potentiometer on
the interface board; constant speed, which is much like the cruise control systems in vehicles today; and constant distance, in which the virtual vehicle maintains a specified distance between itself and the virtual car immediately in front. IV. R ESEARCH IN THE E MBEDDED C ONTROL L AB Although the embedded controls laboratory at Michigan is primarily a teaching laboratory, the technology used in course exercises also offers ample opportunities for research. Indeed, the research and teaching roles of the laboratory are synergistic, in that research results are used in the teaching lab and phenomena observed by students inspire additional research. For example, the driving simulator used in the adaptive cruise control project was originally developed for a driver distraction study conducted by Professor Gillespie and a PhD student [11]. The initial course development was supported by the NSF CRCD grant EIA-0088064. A subsequent NSF grant, EHS-0410553, supported research into haptic interfaces and teleoperator systems, and the limitations imposed by the mechanical haptic hardware. This led us to replace the original belt-driven haptics in the embedded control lab with a direct drive version. As a consequence, students experience phenomena not possible due to the flexibility in the belt. In particular, coupling physiological systems to virtual environments gives rise to many interesting phenomena, one of which is the appearance of dissipativity in the coupled dynamics, the source of which is difficult to identify. With the support of our current NSF grant, CNS-1035271, we are developing a model [12] that explains the dissipativity, so that we can incorporate it into our course materials, and gain better understanding of the complexities of coupled cyber-physicalphysiological systems. R EFERENCES
[1] J. S. Freudenberg and B. H. Krogh, Industry Needs for Embedded Control Education, Proc. American Control Conference, June 2005. Portland, OR. [2] L. Brooke, Computer Code an Increasingly Precious E.V. Commodity, The New York Times, January 21, 2011. www.nytimes.com/2011/01/23/ automobiles/23SPIES.html. [3] J. P. MacDuffie and T.Fujimoto, Why Dinosaurs Will Keep Ruling the Auto Industry, Harvard Business Review, June 2010. [4] W. P. Milam, The 21st Century Automobile and Cyber-Physical Systems, December 2007, http://varma.ece.cmu.edu/CPS-Auto/rtss CPS milam.pdf. [5] R. B. Gillespie, M. B. Hoffman, and J. S. Freudenberg, Haptic interface for hands-on instruction in system dynamics and embedded control, Proc. 11th Haptic Symposium, March 2003, pp. 410-415. [6] http://web.eecs.umich.edu/∼jfr/embeddedctrls/index.html [7] J. S. Freudenberg and J. A. Cook, “Embedded Controls Education at the University of Michigan”, Mathworks News and Notes, 2009. www.mathworks.com/company/newsletters/news notes/2009/ embedded-control-systems.html [8] J. S. Freudenberg, “Teaching Embedded Control Systems at the University of Michigan”, Mathworks Webinar, February 2010. www.mathworks. com/company/events/webinars/wbnr42281.html [9] www.mathworks.com [10] http://www.idsc.ethz.ch/Courses/embedded control systems [11] P. G. Griffiths and R. B. Gillespie, Sharing Control Between Humans and Automation Using Haptic Interface: Primary and Secondary Task Performance Benefits, Human Factors, Fall 2005 47: pp. 574-590. [12] B. Yu, J. S. Freudenberg, R. B. Gillespie, and J. Cook, Dynamic Coupling between a Human User and Haptic Virtual Environment, Proc. 51st IEEE Conference on Decision and Control, Dec. 2012, Maui, HI.
J. S. Freudenberg
Dept. of Electrical Engineering and Computer Science University of Michigan Ann Arbor, MI 48109-2122, USA Email: jfr@umich.edu
J. A. Cook
Dept. of Electrical Engineering and Computer Science University of Michigan Ann Arbor, MI 48109-2122, USA Email: jeffcook@umich.edu
Abstract—We currently teach a popular class in embedded control systems at the University of Michigan and at ETH Zurich, with total enrollment to date over 1200 students. The course was developed, with NSF support, before the term “cyberphysical system” came into vogue. Nevertheless, many topics relevant to a cyberphysical system curriculum are covered in the lectures and laboratory exercises. These include networked control, hybrid dynamical systems, human computer interaction, and modelbased software development. In this paper, we describe the class, its motivation in a request from an automotive OEM, and the associated embedded control laboratory. We close with a discussion of the research conducted in the laboratory, and the synergy between this research and the instructional mission of the lab.
I. I NTRODUCTION For many years we have been teaching a popular class in embedded control systems at the University of Michigan (since 2000) and ETH Zurich (since 2008). At the time the course was conceived and developed, the term “cyberphysical system (CPS)” had yet to be coined. Yet many of the topics discussed in the class are relevant to a CPS curriculum. In the present paper, we describe the content of the embedded control class as it is currently taught, and its origins in a request from industry. The paper is an updated version of one presented in 2005 that focused on industry needs for embedded control education [1]; these needs have only grown since that time. The reader will note several CPS topics that are are covered in the class, including networked and distributed control, hybrid dynamical systems, human-computer interaction, and modelbased software development. Responding to a request in 1998 from the local automotive industry, a new class was created at the University of Michigan, EECS 461: Embedded Control Systems [1]. The industry contact1 noted that traditional undergraduate degree programs were ineffective in producing engineers with the skills required to develop the complex embedded control software required in current automobiles. Electrical engineers with knowledge of control algorithm development were completely unfamiliar with how to implement such an algorithm on an embedded microprocessor. Computer engineers familiar with microprocessors had little or no experience with control algorithms.
1 Dr. Kenneth Butts, then working at Ford Motor Company, and currently with Toyota Technical Center.
The lack of a common knowledge base resulted in engineers who found it difficult to collaborate on the multidisciplinary teams required for embedded control software development. At the time, the automotive industry was faced with the daunting task of developing the software that runs on the numerous embedded and networked microprocessors that were being used to control such new features as variable cam timing and electronic throttle. The move to hybrid and electric vehicles, and the introduction of vehicle-to-vehicle and vehicle-toinfrastructure communication to enable such safety features as adaptive cruise control and collision avoidance systems, has only accelerated this trend. For example, it is estimated that a Chevrolet Volt or a typical Ford vehicle contains 10 million lines of code [2], [3], and the automotive sector is often cited as a prime motivator for CPS research [4]. At Michigan, EECS 461 is taught to senior undergraduate students in electrical engineering and computer engineering, and attracts graduate students in civil, mechanical, aerospace, bio-medical and other fields. The class is currently being offered three times a year, and serves up to 72 students each semester, a number limited only by available laboratory facilities. The ETH Zurich version of the class is offered once a year as a short course to 33 mechanical engineering graduate students. It is one of the challenges of EECS 461 to provide students with such a wide range of academic backgrounds with the knowledge and skills required to work effectively and immediately on embedded control software development. Skills addressed by this class within a model-based embedded control software design paradigm include: modeling and analysis of hybrid-dynamical systems; design of control and signal processing algorithms including frequency response, sampling and aliasing; an understanding of computer hardware including issues of interfacing, memory, and timing; computer software, emphasizing multitasking, numerical methods and real-time computation; sensors and actuators; and distributed control over networks The course employs a Freescale MPC5553 microcontroller and a single-axis haptic interface – the one used at ETH Zurich is shown in Figure 1. As shown in Figure 2, the haptic interface allows a human user to interact, through the sense of touch, with a virtual reality algorithm implemented on a microprocessor. The overall system depicted in Figure 2
The remainder of this paper is outlined as follows. In Section II we describe the MPC5553 microcontroller and haptic interface; Section III describes the laboratory exercises and topics covered in the course, including the final project; Section IV discusses some of the research being carried out in the embedded control systems laboratory. Many of the Michigan course materials are available on the website [6]. Information about the class can be found in the article [7] and webinar [8]. II. E MBEDDED C ONTROL S YSTEMS L ABORATORY The laboratory consists of five major components: an embedded microprocessor, a software development environment, a force-feedback haptic interface, the CAN network that connects the individual processors, and the MATLAB based environment for automatic code generation. The microprocessor used in the EECS 461 laboratory is the MPC5553, the current generation Freescale microcontroller originally developed for automotive powertrain control, but now widely applied across many industries. The 132 MHz 32-bit PowerPC controller2 is able to process a large number of inputs and outputs. For example, the microcontroller incorporates two programmable enhanced Time Processing Units (eTPUs) that are separate processors used to handle I/O that would otherwise require either a separate chip or CPU interrupt service. In the embedded control systems course, this peripheral device is employed along with an optical encoder to determine the position of the haptic wheel using quadrature decoding. The MPC5553 has 1.5 MB of embedded Flash, 64 KB on-chip static RAM, an 8 KB cache and supports 210 selectable-priority interrupt sources. Other peripherals include 2 40-channel ADC, and a 24-channel programmable enhanced Modular Input/Output Subsystem (eMIOS) that can be used for timing, input signal capture and output signal generation such as PWM. In EECS 461, the eMIOS is used to control the haptic interface DC motor via a PWM amplifier in current control mode. The software development environment includes a C compiler and in-circuit debugger. Haptics are used in many application domains, and will be essential in X-by-wire cars, wherein mechanical linkages between the driver and the automobile are replaced by electronics. They do represent a challenging embedded control task, in part because the human haptic sensor, i.e., the sense of touch, has a bandwidth in the range 500–1000 Hz. This implies that the embedded software used to update the virtual reality simulation with which the human interacts must satisfy rather fast timing constraints. The final component of the laboratory is the software used to support model-based control software development. Each workstation is equipped with MATLAB, Simulink, Stateflow, and Simulink Coder (formerly Real-time Workshop), all products of the MathWorks [9]. An OSEK compliant real-time operating system (RTOS) is used to implement multi-rate tasks within a system modeled in Simulink.
2 The MPC5553 microprocessor is operated at 120 MHz in the embedded systems laboratory.
Fig. 1.
Single Axis Haptic Interface used at ETH Zurich.
behavior sensor (taction and kinesthesia) position velocity force sensor (encoder)
Human
actuators (muscles)
Haptic Device CPU
algorithm (virtual environment)
force
actuator (DC motor)
Fig. 2. A physical system (the haptic interface) allows interaction between a cyber system (the virtual world) and a physiological system (the human).
thus has cyber, physical, and even physiological components. Working in teams of two, students implement several virtual environments that can be manipulated through the haptic device, beginning with a virtual wall and finishing with a networked multi-vehicle driving simulator. Essentially every laboratory exercise requires modeling and simulation using tools such as MATLAB, Simulink, and Stateflow, before code is written. Initially, low-level programming is accomplished in handwritten C to develop an understanding of the hardware; ultimately, an extensive driving simulator project is developed using code automatically generated from the system model in Stateflow and Simulink. The teaching laboratory features six workstations each with an MPC5553 development board, a host computer, a custom interface card, and the haptic interface. The workstations are all connected through a Control Area Network (CAN) bus. The haptic interface is essentially a wheel driven by a DC motor in torque control mode using a PWM signal generated by the MPC5553 in response to a change in wheel position as measured by an optical encoder. The specific haptic interface we use at Michigan was developed by Professor Brent Gillespie of the Mechanical Engineering Department. The original version of this device, as described in [5], has now been replaced by a direct drive version similar to that in Figure 1.
III. L ECTURE AND L ABORATORY T OPICS During a fourteen week semester at the University of Michigan, students perform eight 3-hour laboratory exercises and a 4-week final project. There are two 90-minute lectures per week. Each laboratory exercise reinforces a concept taught in lecture, and teaches a different peripheral device on the MPC5553. Furthermore, each lab exercise builds on the previous one, so that throughout the semester students develop a library of software routines that will be reused. The course has been taught once during the abbreviated, seven-week, Spring term at Michigan, and is taught as an intensive (8 hours/day) 2-week block course at ETH Zurich [10]. The fields of embedded control and CPS are highly multidisciplinary, and this fact requires that the lectures and lab exercises cover a broad range of topics, so that students see how they fit together in an application, and begin to appreciate design tradeoffs that must be made across disciplinary boundaries. Initial lecture topics include sampling and quantization, quadrature decoding for position and velocity measurements, frequency response, pulse width modulation, DC motors and motor control. Haptic interfaces are discussed, together with some simple virtual reality environments that students implement in the lab. These include the virtual wall, in which a virtual mechanical stop is implemented to prevent the wheel from rotating past a certain point, and the virtual spring mass system, in which the wheel is made to behave as though it were attached to a virtual wheel through a torsional spring. In the first instance, students will experience an artifact of the digital implementation referred to as “wall chatter,” a high frequency vibration due, in part, to sampling and quantization. In the second case, students will be introduced to real-time numerical algorithms used to implement the virtual dynamic system and understand the tradeoffs among speed, simplicity and numerical stability. Students are required to construct Simulink models of the virtual worlds they create, and to make sure that their algorithms work in simulation before they are allowed to implement them in the lab. In particular, the virtual wall is a simple hybrid dynamical system that the students learn to model using Stateflow. Computing issues covered in lecture include interrupt processing, shared data problems and multitasking, plus concepts from real-time operating systems such as task states and priorities and semaphores. The problems of deadlock and priority inversion are discussed, together with advanced approaches to shared data such as the priority inheritance and priority ceiling protocols. Topics in real time computation include a discussion of rate monotonic analysis and earliest deadline first scheduling. Emphasis is placed upon networked control, as students must implement force feedback algorithms over a CAN bus. A. Laboratory Exercises and Project The eight laboratory exercises start with implementing simple digital inputs and outputs, and extend to automatic code generation and distributed system implementation.
Lab 1, Familiarization and Digital I/O: In the first exercise, students learn to write C for embedded applications and to perform low level bit manipulations needed to access special purpose registers in the memory-mapped processor. In this simple “Hello World” exercise, students read two 4-bit numbers from DIP switches, sum them, and echo the result to LEDs. Lab 2, Fast Quadrature Decoding Using the eTPU: Here, students interface the optical encoder on the haptic wheel to the time processing unit on the microcontroller (using the general purpose I/O learned in the first exercise), and use the quadrature decode function to measure the position of the wheel. Students compute the maximum rate at which the haptic wheel can turn before the count register associated with the eTPU over/underflows and the MPC5553 loses track of position. Lab 3, Analog to Digital Conversion: Students learn to program the eQADC module on the MPC5553, and perform timing analyses to determine how long the conversions take. With this information, students investigate aliasing, and demonstrate the sampling concepts discussed in the lectures. Lab 4, Pulse Width Modulation and Introduction to Simple Virtual Worlds: The DC motors used to provide force feedback are driven by a PWM amplifier that, in turn, is driven by the programmable eMIOS on the MPC5553. In this exercise, students learn to program this module and use it to construct their first example of a virtual reality, the virtual wall described above. To do so, the processor implements a force feedback law stating that if the wheel “penetrates” the virtual wall (i.e., turns past the position of the virtual stop), then a strong restoring force proportional to the penetration distance is applied, effectively a virtual spring. Students are required to work with the conversion factors between wheel angle and encoder counts, and between PWM duty cycle and torque, so that a prescribed penetration corresponds to the software limited maximum motor torque. Lab 5, The Periodic Interrupt Timer and Frequency Analysis of PWM Signals: Simple virtual worlds such as the virtual wall can be implemented in a software loop, and do not require a concept of time, as would be needed for numerical differentiation or integration. More complex worlds do require a time step, and students learn to supply this using one of the interrupt timers on the MPC5553. In this lab they create an interrupt routine that modulates the eMIOS PWM duty cycle by sampling a sine wave. When the resulting signal is passed through a hardware filter and displayed on an oscilloscope, the sine wave is recovered. Students write and measure the execution time of three different interrupt routines to obtain the sine wave samples: by sampling the output of a signal generator, by using the C sine function, and by using a lookup table. This reinforces that three functionally equivalent approaches to the same task can impose very different timing demands upon the processor. Lab 6, Virtual Worlds with Time: Using the interrupt routines developed in the previous lab, virtual worlds that require numerical integration or differentiation can be imple-
mented. In this lab, students program the MPC5553 to simulate the effect of a virtual wheel attached to the physical wheel with a virtual torsional spring. The virtual inertia and spring constant must be chosen so that, in response to a 45◦ step in the physical wheel, the virtual inertia will oscillate at 1 Hz, with a specified maximum torque. Before the students begin writing software to implement the virtual inertia, they are required to develop a Simulink model to verify that their force feedback algorithm, if implemented correctly, will have the desired behavior. Students use forward Euler numerical integration, because it is easier to implement in real time. This, however, results in instability. Students are asked to compute the amount of virtual damping needed to offset the destabilizing effect of the Euler integration, and verify the result in simulation, before testing their code on the haptic wheel. Lab 7, Controller Area Networking: The six workstations in the EECS 461 lab are connected over a CAN network. In this lab students learn to transmit and receive messages over the CAN bus. They first implement a virtual wall over the network, and experience degradation in the quality of the wall they can implement due to networking delay. They then implement a virtual chain of wheels – when one is turned all the wheels in the room also turn using a simple position tracking algorithm. If the position of one wheel is held constant, then the person turning the master wheel experiences an opposing force. Students find this lab challenging because everyone must write code to the same standard to enable communication, and especially because of the complexity of debugging distributed software. Lab 8, Introduction to Autocode Generation: To this point, all the embedded software has been implemented in handwritten C code, although Simulink modeling has been used to verify that the force feedback algorithms have the correct functionality. In this lab, students generate embedded software directly from Simulink and Stateflow diagrams. To do so, they use Simulink Coder from the MathWorks, the Freescale RAppID development system that implements a set of device driver blocks for the MPC5553, and an OSEK compliant RTOS used to specify task priorities and to address shared data issues. Students construct a Simulink model of two virtual wheels with significantly different natural frequencies, thus motivating an implementation in task states executed with different periods and, consequently, different priorities. Project: Students use the knowledge gained in eight laboratory exercises to design and implement a driving simulator using the haptic wheel to steer a mathematical vehicle model along a virtual road. Ultimately, every team’s driving simulator is connected via CAN and simulated on a single road. Students implement an adaptive cruise controller to maintain a preset distance between virtual cars on the road. The project requires about four weeks, and student teams implement their driving simulators entirely in code generated from Simulink and Stateflow models. Stateflow is particularly valuable in describing the three required operating modes: manual, in which the speed of the virtual car is controlled by a potentiometer on
the interface board; constant speed, which is much like the cruise control systems in vehicles today; and constant distance, in which the virtual vehicle maintains a specified distance between itself and the virtual car immediately in front. IV. R ESEARCH IN THE E MBEDDED C ONTROL L AB Although the embedded controls laboratory at Michigan is primarily a teaching laboratory, the technology used in course exercises also offers ample opportunities for research. Indeed, the research and teaching roles of the laboratory are synergistic, in that research results are used in the teaching lab and phenomena observed by students inspire additional research. For example, the driving simulator used in the adaptive cruise control project was originally developed for a driver distraction study conducted by Professor Gillespie and a PhD student [11]. The initial course development was supported by the NSF CRCD grant EIA-0088064. A subsequent NSF grant, EHS-0410553, supported research into haptic interfaces and teleoperator systems, and the limitations imposed by the mechanical haptic hardware. This led us to replace the original belt-driven haptics in the embedded control lab with a direct drive version. As a consequence, students experience phenomena not possible due to the flexibility in the belt. In particular, coupling physiological systems to virtual environments gives rise to many interesting phenomena, one of which is the appearance of dissipativity in the coupled dynamics, the source of which is difficult to identify. With the support of our current NSF grant, CNS-1035271, we are developing a model [12] that explains the dissipativity, so that we can incorporate it into our course materials, and gain better understanding of the complexities of coupled cyber-physicalphysiological systems. R EFERENCES
[1] J. S. Freudenberg and B. H. Krogh, Industry Needs for Embedded Control Education, Proc. American Control Conference, June 2005. Portland, OR. [2] L. Brooke, Computer Code an Increasingly Precious E.V. Commodity, The New York Times, January 21, 2011. www.nytimes.com/2011/01/23/ automobiles/23SPIES.html. [3] J. P. MacDuffie and T.Fujimoto, Why Dinosaurs Will Keep Ruling the Auto Industry, Harvard Business Review, June 2010. [4] W. P. Milam, The 21st Century Automobile and Cyber-Physical Systems, December 2007, http://varma.ece.cmu.edu/CPS-Auto/rtss CPS milam.pdf. [5] R. B. Gillespie, M. B. Hoffman, and J. S. Freudenberg, Haptic interface for hands-on instruction in system dynamics and embedded control, Proc. 11th Haptic Symposium, March 2003, pp. 410-415. [6] http://web.eecs.umich.edu/∼jfr/embeddedctrls/index.html [7] J. S. Freudenberg and J. A. Cook, “Embedded Controls Education at the University of Michigan”, Mathworks News and Notes, 2009. www.mathworks.com/company/newsletters/news notes/2009/ embedded-control-systems.html [8] J. S. Freudenberg, “Teaching Embedded Control Systems at the University of Michigan”, Mathworks Webinar, February 2010. www.mathworks. com/company/events/webinars/wbnr42281.html [9] www.mathworks.com [10] http://www.idsc.ethz.ch/Courses/embedded control systems [11] P. G. Griffiths and R. B. Gillespie, Sharing Control Between Humans and Automation Using Haptic Interface: Primary and Secondary Task Performance Benefits, Human Factors, Fall 2005 47: pp. 574-590. [12] B. Yu, J. S. Freudenberg, R. B. Gillespie, and J. Cook, Dynamic Coupling between a Human User and Haptic Virtual Environment, Proc. 51st IEEE Conference on Decision and Control, Dec. 2012, Maui, HI.