Embedded Control Systems (H04P5)

(Applied to “intelligent mechanics”)

Staff | Admin | Contents | Learning goals | Evaluation | Project

Teaching staff

Lecturer	Address	Teaching assistant 1	Teaching assistant 2
Herman Bruyninckx		Markus Klotzbücher	Zhang Lin
	K.U.Leuven Dept. Werktuigkunde Room 01.053 Celestijnenlaan 300B B-3001 Leuven (Heverlee) Belgium

Administrative matters

The official K.U.Leuven course description can be found here: H04P5AE.

Place and time of first lecture (second semester 2010–2011): 16 February 2011, 10h35–12h35, Room C300-03.42 (SEM.LOK.C).

Timing: the K.U.Leuven course system has foreseen the following contact moments:

• Lectures: 16.02, 23.02, (02.03, no lecture!), 09.03, 16.03, 23.03, 30.03, 06.04, 27.04, 04.05, 11.05 and 18.05.

• Project: Tuesdays 22 Feb, 8 Mar, 22 Mar (14h00–16h25), and 5 Apr, 26 Apr, 3 May, 10 May, 17 May (16h35–19h00). Place: Robot Lab, C300, first floor.
  For practical reasons, the course's learning goals cannot be nicely divided over these scheduled practical sessions, so we will not strictly follow this lecture and project schedule. Students are expected to do the “homeworks” and “assignments”, and prepare two “design deliverables”, on their own, making use of the opportunity of on-line or personal interactions with lecturer and teaching assistants. On the days in bold, we do expect everybody to be present in the robot lab, for demonstrations of embedded systems by the teaching assistants.

Course contents: an overview

This course is an introduction to embedded control systems, with an emphasis on intelligently moving machines, i.e., robots, cars, trucks, machine tools, airplanes, satellites, etc. The goal is to introduce the students to the knowledge and the expertise required for a project engineer in a company that designs and develops such embedded control systems. Strong emphasis is on systems level thinking (i.e., every part of the system is selected and tuned for the goals of the whole system), on design (i.e., comparison of possible alternatives should be done on the basis of informed and motivated argumentations), and on design automation, i.e., what standards and tools exist to support the design in large-scale projects, in which no single person can keep the overview and control of the whole design process.

Learning goals

The course has three study points, corresponding to about 75 hours of effort from each student. These efforts are spent on the three following learning goals:

• Knowledge (20 hours): students master a set of essential concepts and techniques in embedded systems for motion control. These concepts are introduced in the lectures, and further elaborated by the students in a series of weekly, small “homeworks”.

  Students will be introduced to a lot of encyclopedic knowledge on the components and systems that are relevant in modern and future embedded control systems. The goal is not to memorize all this knowledge, but to understand the major concepts, how they fit together in a large-scale systems thinking, and where to find the detailed technical information when needed.

• Skills (35 hours): students learn how to use the traditional “embedded systems toolchain”, via a series of small programming assignments. In addition, they are introduced to the modern pragmatics of (many but not all) embedded systems development companies. Summarized in one line, this means: Linux, Eclipse, Wikis, mailing lists.

  A strong emphasis is put on the role of software in embedded control systems. The motivations are two-fold: (i) it is an industrial reality that software provides a steadily growing part of the “added value” in embedded systems, and (ii) too few other courses in our curriculum provide opportunities to get hands-on experience with the embedded software aspects of modern and future machines.

• Research (20 hours): students must show that they can apply the learned concepts and techniques to think of new, innovative applications, more in particular they will “design” an embedded system that can potentially hit the market in five to ten years.

  This part of the course works by putting the student in the role of the Chief Technical Officer of a medium-sized, innovation-driven embedded systems company (of which one can find a dozen or so at the K.U.Leuven's research parks in Haasrode or Heverlee!). His or her responsibility is to come up with a realistic vision about a new embedded technology.

Evaluation

Evaluation takes place via continuous evaluation. Hence, there will be no examination session in June, but progress is evaluated as follows:

• Knowledge: via the Homeworks, and your contributions to the optimal use of the mailing list.
• Skills: via one session towards the end of the semester, in which you show the teaching team what you have learned from the Assigments. (The concrete schedule for this session will be put online after the Eastern holiday.)
• Research: (i) face-to-face discussions with the teaching staff (to be requested by individual students when necessary), (ii) Deliverable 1 and Deliverable 2
  Update (April 1): Deliverable 2 is cancelled; Deliverable 1 is enough (and no written report is required for this Deliverable).

Code of conduct

Each student is expected to follow the rules below, not in the first place because of whatever course requirements itself, but because of their relevance in the modern industrial practice:

• Use your own name (and official K.U.Leuven email address) in all electronic communications: you are responsbile for your own brand, and your “electronic footprint” has the potential to be an invaluable asset in your CV.
• Be open when possible, but secret when necessary: a growing number of embedded systems are being built on top of freely available hardware designs, software code, and documentation. The domains that make the fastest progress are the one that have succeeded in finding an appropriate balance between sharing of knowledge, design and software (for all pre-competitive, common infrastructure) on the one hand, and keeping their differentiating, added value developments secret, on the other hand. Learning how this balance works in the real modern industrial practice is an important part of the Skills that students will learn in this course.
  For example, parts of your research project are better kept top-secret, and you are not expected to communicate about them with other students.
• Homeworks are strictly individual, so the lecturer expects a proof of each individual student that (s)he has done the homework; the deadline is the evening before the lecture following the lecture on which the homework has been assigned. The “proof” depends on the type of the homework: it can be an email, an editing commit on a Wiki, etc. Note that the homework being individual does not mean that it must be secret: as mentioned before, it often makes sense to share and be open towards “the world”, but also in this case each individual's contribution must be tracable.
• Effort hours are 60 minutes each: that means, put your mobile phones away, shut down all your social network sites, put your chat profile on not available, because this course is not paying for your leisure time!
• Use appropriate posting style, more in particular, adhere to what this Wikipedia article has to say about this matter. This course (as most mailing lists for embedded systems engineers) adheres to the inline replying style.
• Consistent use of open electronic formats: only open standard formats for electronic information can guarantee fair and eternal access to the valuable information that you (and your company!) will put onto computers in the coming decades.

Course contents: Spring 2011 details

The following paragraphs explain the concrete contents of the course for the Spring semester 2011. Each Homework and each Assignment represents about three hours of effort.

1. Knowledge

Lecture	Contents
Introduction
	Explanation of course ideas, goals and research project. Illustration of the embedded aspects of robots. Homework 1: subscribe to the course mailing list; make identifiable user account on course Wiki (this need not be your own name, but mail the lecturer about the account name you have chosen!); find three “open projects” that are relevant for this course, and mail the lecturer a motivation of why you think they are relevant, and how useful you find their mailing list. Homework 2: identify three embedded systems (in the intelligent mechanics context of this course, and summarize their three most discriminating factors, that is, the reason why they are successful as embedded system in a competitive market. These reasons are most often technical, but non-technical discriminating factors can exits too! For example (in a different embedded domain than intelligent mechanics!), the Apple iPhone succeeds mostly because of its “coolness factor”.
Embedded hardware
	What is so special about the hardware of “embedded systems”? How broad is the variety of embedded hardware? How do you interface the hardware? How do different (parts of) embedded systems communicate with each other? Homework: find three different vendors that provide embedded hardware relevant for this course; give one concrete example of why a particular product of each vendor is relevant for the course's research project; summarize the development tools each vendor provides.
Levels of complexity — 5Cs
	Not all embedded systems have the same level of complexity, but how does the complexity level influence the design and implementation of an embedded system? Is an industrial robot, a car, or an airplane a complex embedded system? What can we expect in the coming decade? In other words, what should you prepare yourself for as the future innovators in our industry, and what knowledge and skills will that require? This lecture also explains the role of the “5Cs” in embedded systems design: Computation, Connectivity, Communication, Coordination, and Configuration. Homework: describe three examples of embedded control systems (in the intelligent mechanics context, of course) of different complexity levels, and explain what their “5Cs” are.
Asynchronous activities
	Any embedded system with more than trivial complexity requires multiple “activities” to run concurrently. The communication and coordination of concurrent activities is the major technical challenge in the software design of an embedded system. This lecture explains how the hardware supports concurrent activities, and what software design patters are appropriate. Homework: take one particular, realistic example of an embedded control system, and provide the pseudo-code that explains how you would solve one particular case of asynchronous activities in that system. Some examples can be found in this document.
Toolchains
	What are the traditional steps in the development process of an embedded system? How are they supported by software toolchain(s)? Homework: discuss (maximum: half a page) the potential and the risks of Model-Driven Engineering toolchains for your preferred embedded systems sub-domain in intelligent mechanics.
FPGA-based robot control system
	This seminar (April 26th, 2011) illustrates the use of “programmable hardware” (FPGAs) as one possible way to make a (very dedicated, high-performance) embedded control system.

2. Skills: building the software of a small mobile robot

See the Assignments web page.

3. Research: virtual traffic light coordination

Description: in this project, you design a distributed embedded control system with which “cars” can communicate and coordinate their access to a road crossing, as an alternative to the traditional traffic lights.

The communication between the cars is, in itself, only the smallest problem to be solved, since the real challenges are in making the virtual traffic light robust (against lots and lots of adversary circumstances that can occur in real traffic conditions), safe, effective, efficient and future proof.

Deliverable 1 (18 hours): a (not more than) one-page description of your innovative design, with an outline of how you think it should be implemented.
Update (April 1): the report for this Deliverable is cancelled; the oral discussions with the lecturer about your research project are enough.

Deliverable 2 (2 hours): each student will get five of the above-mentioned one-page project descriptions to review. Each review should be limited to a bulleted list of maximum five items.
Update (April 1): this Deliverable is cancelled.

Most of the efforts for the project will be spent in the later half of the semester, in order to profit from what is learned in the Homeworks and Assignments. The deadlines for these Deliverables are fixed after consultation with the students.