Course Syllabus

Jump to Today

Welcome

Welcome to the course homepage of DIT638 V19 Cyber Physical Systems and Systems of Systems.

The course is given by the Department of Computer Science and Engineering at Campus Lindholmen during Study Period 4, 2019. You find information about the course below.

Course-PM

Course coordinator and Examiner

Dr. rer. nat. Christian Berger, Associate Professor                            christian.berger@gu.se

Supervisors:
Dr. Yue Kang, Postdoc yuek@chalmers.se
Federico Giaimo giaimo@chalmers.se 
Hugo Sica de Andrade sica@chalmers.se 

Student supervisors:
Karanveer Singh
Firas Cheaib
Margit Saal
Fahd Debbiche


Supervision will take place in Mållgan during these slots:

Mondays: 10am - 12pm: Margit, Fahd, Karanveer
Tuesdays: 10am - 12pm: Margit, Firas Karanveer
Thursdays: 10am - 12pm: Fahd, Firas, Karanveer
Fridays: 10am - 12pm:  Margit, Firas, Fahd

Course evaluation results

The results from the course evaluation questionnaire is now published. 

Protocol: https://canvas.gu.se/courses/22424/files?preview=1643482

Results: https://canvas.gu.se/courses/22424/files?preview=1643490

 

Course content

Today’s vehicles are equipped with many embedded systems to provide comfort and safety func-tions to the driver, passengers, and other traffic participants. The development of these vehicle functions requires nowadays the combined knowledge and teamwork of different disciplines like computer science, electrical engineering, and mechanical engineering. Moreover, these functionali-ties shall be developed in tighter schedules with the same or even better quality for several vehicle families.

The purpose of this course is to familiarize the student with contemporary challenges and technologies for developing self-driving vehicles. But instead of working with real vehicles, this course is working with scaled variants to allow the students to develop autonomous lane following behavior, safe handling of intersections, passing other vehicles, and to park vehicles.

The course covers the following aspects:
▪ Analyzing requirements documents provided by the customer (cf. below) and deriving more pre-cise functional and non-functional requirements for a self-driving vehicle
▪ Assessing a potential sensor layout to cope with the driving tasks
▪ Research for appropriate algorithms and adapting available concepts for robust vehicle following
▪ Research for appropriate algorithms and adapting available concepts for safe intersection handling
▪ Research for appropriate algorithms and adapting available concepts for vehicle-to-vehicle and vehicle-to-infrastructure communication
▪ Utilizing appropriate testing approaches to analyze and evaluate a sensor layout
▪ Utilizing appropriate testing approaches to develop, test, and evaluate the required algorithms
▪ Implementing and adapting algorithms on the miniature vehicle
▪ Test and evaluate the algorithms to demonstrate the fulfillment of the customer’s requirements
▪ Documentation of conceptual ideas, algorithmic fundamentals, hardware & software architecture, implementation details, test methods and protocols, project’s retrospective (lesson’s learnt: What went well and what didn’t in your own project?)
▪ Creating presentations with required topics during the project and giving oral presentations

 

Schedule

You will find the schedule here.

 

Course Literature

Introductory course literature is

Martin Buehler, Karl Iagnemma, Sanjiv Singh: The DARPA Urban Challenge: Autonomous Vehicles in Urban Traffic, Springer, 2009

Christian Berger: From a Competition for Self-Driving Miniature Cars to a Standardized Experimental Platform: Concept, Models, Architecture, and Evaluation. Journal of Software Engineering for Robotics, vol. 5, no. 1, 2014, pp. 63-79 (http://arxiv.org/abs/1406.7768)

In addition, tool-related documentation (for example: https://chrberger.github.io/libcluon/index.html or  https://github.com/chrberger/libcluon#tutorials--api-documentation) as well as recent research publications will be extensively used. Additional supplementary literature will be published on Canvas during the course where necessary. Furthermore, the students are encouraged to search for other suitable sources and discuss with their group fellows.

More related literature:

  • Gary Bradski& Adrian Kaehler: Learning OpenCV Computer Vision with the OpenCV Library. O'Reilly Sebastopol.
  • PeterCorke: Robotics, Vision, and Control Fundamental Algorithms in MATLAB. Springer VerlagBerlin Heidelberg.
  • Detecting cars in videos

Course design

The course’s overall pedagogical strategy is problem-based learning. Learning proceeds by group-work, in which authentic problems are addressed. Learning is student directed and student cen-tered. The teachers’ and student assistants’ roles are to facilitate the acquisition of knowledge among participants.
 
Several learning resources are provided: 
• Learning goals (cf. above) define what should be learnt.
• Problems “drive” the study activities. To facilitate the right kinds of learning, problems are purposely non-trivial.
• Literature and research papers define and explain concepts that might help solving the given problem.
• Tools support practical exploration of the studied concepts.
• Introductory lectures (cf. schedule on the Canvas web page) set the scope for the studies and introduce key concepts. They introduce and supplement literature but they do not substitute it, and they guide students’ discussions. The role of the lectures is to introduce the participants to the project’s topics and to “kick-start” the learning process; the role is not to cover everything to be learned or “ready-to-use”-solutions. Lectures are concen-trated and aim to focus on the big ideas and point out some difficult aspects. Solving the problems, however, usually means going beyond what is covered in the lectures.
• Student assistants’ supervision sessions (cf. most updated schedule on the course’s web page) guide students’ discussions and problem solving strategies.
• Groups help with knowledge sharing, building collective know-how, collective thinking, dividing of work, discussing of solutions, giving feedback, articulation, motivation and many other things.
o Groups ideally consist of 4 people (depending on the number of registered course participants). 
o Group formation is a student responsibility. 
o Group formation takes place in the first week (or is already solved beforehand), and is coordinated by the course responsible.
o The goal to develop a self-driving vehicle is only achievable as a team!
• Joint presentations in which groups present approaches and solutions and give feedback.
• Self-directed group work in which groups organize their work and elaborate solutions on their own. 
The Canvas pages are used for teacher-to-student, student assistant-to-student, student-to-student, and teacher-to-student assistant communication. Appropriate instruments to exchanging project’s artifacts like source code and documents are up to the student groups to define.

 

Project Organization

The course responsible will act as product customer and formal examiner. Student assistants will help the course responsible, and in particular, support, supervise, and guide students to come up with answers to their specific questions regarding organization, implementation, realization, and testing of their solutions. Therefore, the most recently updated weekly schedule of student assis-tants’ supervision is provided on Canvas. In addition, introductory lectures will also be announced on Canvas to introduce key concepts. It is the students’ obligation to check regularly Canvas for further information.


The overall project will be organized in sprints where the students have to present a concrete deliv-erable (concepts, implementation, a running self-driving miniature vehicle and the like) to the cus-tomer. The sprints’ schedule will be announced and updated on Canvas.


Student organization: The project allows for students to formulate their organization as they see fit but will be under the requirement of having motivated their decisions for how to work for the course responsible and his comments on potential weak points. Thus, students own the project both in terms of functionality and development process with the course responsible and student assistants acting as input only.


Hardware and software resources: Preassembled hardware kits will be lent to the student groups so that they can evaluate their algorithms. We strongly advise to use the preassembled hardware kit for the course; the preassembled hardware kits must be handled with care! Only under special circumstances will the course responsible provide additional resources or find adequate solutions with the students. These additional resources from the course responsible will be subject to the existing and official purchasing channels that the university must follow according to the law, and is subject to the (often slow) approval process for course expenses that all university courses must follow.

 

Project Details

Implementation contributions are asked from all members of the project but it is not mandatory that all do “as much” or “as difficult parts” or even necessarily on the embedded hardware like oth-er group members. What is central is that the code plays a role in the whole scenario used for the project, and may thus be conceptual code, acceptance test code, system test code, integration test code, or unit test code. Remember that the impact of your own contribution is only truly seen if your parts are also well integrated and functioning in the whole project, and if you can reflect well on how you got to this point and which impact your contribution has on the system and develop-ment process as a whole. If you are not primarily coding, you have to document your contri-butions traceably to allow examination.


In the same way as with coding, it is expected from all to have done at least some parts of testing, as in particular unit testing should be considered a natural part of good coding practices. Since the project aims for realizing a real embedded system, major focus is also on the integration of software and hardware.


Management of anything from internal group activities to external communication and customer communication (i.e. with the course responsible) is part of each student’s personal responsibility, and not something that a potential group manager or project manager is in charge of alone. It is the responsibility of all to make the most of the project. Obviously, group plans are examples of arti-facts that are likely to be primarily under the responsibility of one or at the most two people in a group that essentially will act as group responsible(s). Empowerment, motivation, and creativity should be three keywords to work heavily towards in managing groups and the project as a whole but in particular for management related issues. The student groups are advised to use proper artifact versioning to organize and document their work (for example, regularly pushing changes to the code to traceably document contributions).

Regardless of the area of work that a student is in, keeping a personal log of daily work, where you note down whatever is on your mind that particular day is a great way to make sure that you will increase your chances to successfully argue and show many of the learning goals are met. Aside from helping with traceability, execution, and improvement, they also serve a very useful role in something as hand-on as reporting time (remember that you will not be asked to report time in this project but reporting time appropriately is important in industrial projects)! Write down why you did something or reached a certain conclusion to demonstrate your contributions later on.

Finally, documentation is to be viewed as mandatory for all. Identifying effective and appropriate levels and ways of documentation is what is central to good iterative software development. The process for writing, reviewing, and managing documents is viewed as part of each task. Thus, documentation should not be viewed as a management task or for some people only but rather as a natural step of requirements management, architecture & design, implementation, testing, as well as group & project management. How to structure and work with documents that many authors are likely to write some parts in is therefore viewed as part of the project challenge and an opportunity for students to show deeper levels of understanding related to large-scale software development.

 

Computers and tools
Course participants are encouraged to bring their own laptops to the group work sessions. Work-ing with the preassembled hardware kits next to the actual software development is encouraged to be conducted on a recent Linux system (for instance Ubuntu 18.04 LTS). Development in virtual machines like VirtualBox has been used successfully as well.

Support from the course responsible as well as the student assistants is only provided for the provided Ubuntu 18.04 LTS.

Communication

Course communication is done through Canvas. It is the students’ obligation to register themselves with Canvas and to check the site regularly.

Examination form

The course is examined as follows:

  • The overall achievements from the team to realize a self-driving miniature vehicle according to the provided customer requirements/scenario will be considered.
  • Each student has to contribute to software and/or hardware/software integration (it is not mandatory that all do “as much” or “as difficult parts” on both levels):
    • The student’s individual contribution must be easily traceable by the examiner.
    • For the software parts, the students must use regularly the group’s artifact versioning repository for the traceability (at least daily or more often when working on the source code).
    • For the hardware/software integration, the students are required to maintain a logbook to protocol their contributions. The feedback from the student assistants supervising the hardware/software integration will also be considered.
    • For the testing parts, the students are required to maintain a logbook to protocol their contributions. The feedback from the student assistants supervising the testing will also be considered.

 

  • Each student group has to write one final and joined product documentation, which covers the following aspects and which must be delivered before the final oral examination:
    • The document must be written in English.
    • Add the full names of all student group members to the beginning of final product document.
    • Allowed document format: PDF
    • Font size: 12pt
    • You must cite the used literature (books, scientific articles and the like) during your implementation/product realization accordingly.
    • Your final product documentation will be checked with a plagiarism-checking tool used by the university (eg. www.urkund.se/SE/documents/Urkunds_plagiathandbok.pdf).
    • Make sure that your document is well-structured, easy to read, and does not contain typos.
    • Each group member must contribute three pages at a minimum and six pages at a maximum; the contribution must be marked clearly on each section/sub-section level in such a way that the examiner can easily trace the student’s individual contribution.
    • The structure of the document is defined as followed:
      1. Table of contents.
      2. Description of the overall students’ individual project organization and milestone planning including a chart covering the successfully completed tasks per milestone to demonstrate the quality of a student group’s planning capabilities. (Percentage of the entire document: 5%)
      3. Conceptual ideas of all algorithmic aspects must be presented accordingly by also employing adequate diagrams. (Percentage of the entire document: 20%)
      4. Necessary algorithmic fundamentals for the robust and reliable detection of the self-driving miniature vehicle’s surroundings by the sensors (camera, ultra-sonic, infrared) and the reliable controlling of the vehicle’s movements for the different driving tasks. (Percentage of the entire document: 20%)
      5. Implementation details that explain selected aspects of the source code. (Percentage of the entire document: 10%)
      6. Description of the software architecture that must be presented accordingly by also employing adequate diagrams. (Percentage of the entire document: 15%)
      7. Description of the hardware/software integration that must be presented accordingly by also employing adequate diagrams. (Percentage of the entire document: 15%)
      8. Description and results from the applied hardware, software, and integration tests. (Percentage of the entire document: 10%)
      9. List of used references for the implementation of algorithmic details (not counted to the students’ individual contribution and also not counted to the overall document’s page limit).
      10. A project’s retrospective covering what went well and what didn’t work out. (Percentage on the entire document: 5%)
      11. Appendix of test protocols and charts where applicable (not counted to the students’ individual contribution and also not counted to the overall document’s page limit).

 

  • In addition to the document, the following files must be provided:
  • The student groups have to orally present their work; details will be defined and announced on Canvas by the course responsible:
    • All student group members must prepare an individual short presentation (up to five slides) covering the topics, which he/she has contributed to the product documentation.
    • The students must orally present their prepared presentation (presentation time 5-10 minutes) and answer the questions from the examiner after the presentation.

 

Grading Scale

  • Fail (U):
    • Failing to demonstrate capabilities to realize a self-driving miniature vehicle according to provided requirements.
    • Failing to provide a final product documentation or the additional files:
      • Non-English submissions
      • Plagiarism:
        • Copying your fellow students (both will fail!)
        • Copying from solutions from previous years
        • Copying content from websites (e.g., source code), online books, or the like
      • Not well structured
      • Not easy to read
      • Not covering the listed topics
    • Failing to orally present the individual contributions and to answer the questions afterwards.
    • Not demonstrating knowledge from learning outcomes (cf. course PM & http://kursplaner.gu.se/english/dit638.pdf)

 

  • Pass (G):
    • Successfully demonstrating capabilities to realize a self-driving miniature vehicle according to provided requirements.
    • Successfully providing a final product documentation covering all topics including the additional files stated under section Examination with sufficient depth.
    • Successfully orally presenting the individual contributions and to successfully answering the questions afterwards.
    • Successfully discussing in a fruitful manner during the oral presentation.
    • Demonstrating sufficient knowledge from learning outcomes (cf. course PM & http://kursplaner.gu.se/english/dit638.pdf)

 

  • Pass with Honor (VG):
    • Everything from “Pass (G)”
    • Continuously demonstrating to take over and carrying out a successful, constructive, encouraging, vital, and clearly visible ownership/leadership role outreaching the own student group throughout the overall course duration that drives the product realization while covering a majority of the following topics:
      • Driving the task planning, tracking, and updating
      • Driving the software architecture planning
      • Driving the software architecture implementation
      • Driving the algorithms’ conceptualizing, implementation, and testing
      • Driving the software/hardware integration and testing
      • Driving vehicle testing
      • Extensive data collection, analysis, and visualization

Examination dates

Examination dates are reserved during the following slots (allocation of student/student group to slot will be conducted after the groups have been formed):

  • Slot A: May 27, 10am – 12pm
  • Slot B: May 27, 1pm – 3pm
  • Slot C: May 27, 3pm – 5pm
  • Slot D: May 28, 10am – 12pm
  • Slot E: May 28, 1pm – 3pm
  • Slot F: May 28, 3pm – 5pm
  • Slot G: May 29, 10am – 12pm
  • Slot H: May 29, 1pm – 3pm
  • Slot I: May 29, 3pm – 5pm

 

Learning objectives and course syllabus

Knowledge and understanding

  • conclude and describe overall system requirements and design, including the system-of-systems aspect

  • elaborate on sub-system requirements and design

  • describe reasons to ensure traceability and select appropriate strategies

  • define incremental development in practice

  • separate and compare different levels and types of testing

  • explain trouble reporting and requirements change routines

Competence and skills

  • plan, conduct, and evaluate software/hardware integration (and is able to show this in terms of code)

  • describe (in terms of code) how system (or sub-system) requirements and system (or sub-system) design has been realized

Judgement and approach

  • reflect on integration work that is done in a project

  • discuss how formal reviewing of artifacts is conducted, recorded and made use of

  • exemplify and elaborate on personnel management, knowledge transfer activities and risk management,

  • exemplify and reflect on daily routines and work-practices that are used in projects

 

CSE Student Pages

https://studentportal.gu.se/english/my-studies/cse/

 

Course Summary:

Date Details Due