How best can embedded systems be learnt? – Project topics materials

Get Complete Project Material File(s) Now! »

Embedded systems and technological practice

Technological practice has three components; the first is brief development which while front loaded is also an ongoing process of teasing out the key aspects of the environment and stakeholders needs. This parallels requirements engineering, and is at the heart of the highly contextual nature of embedded systems. This understanding of context is at the very core of embedded systems where half of the malfunctions come from misunderstandings of clients and environmental requirements (Broy & Stauner, 1999). In software engineering courses learning to elicit requirements has had significant impact on student success (Mohan & Chenoweth, 2011).
The second component of practice is planning, and is an incremental process of developing project management skill within students; the multi-faceted nature of even a simple school-based embedded system includes a veritable maze of hardware, software and environmental aspects that need managing, such as sensors, actuators and user interfaces as well as software design, writing, testing and debugging. Planning of resources including the most valuable asset of time is a core skill needed in embedded systems development.
The third aspect of technological practice is outcome development and evaluation. This is the practical application of methods and skills to realise something. Evaluation is the crucial culmination of practice where the outcome is measured against the specifications elicited by the technologist from the stakeholders and the environment and allows a judgement of the outcomes’ fitness for purpose. Both are standard in embedded systems development, especially so, as evaluation in embedded systems development is so closely intertwined with clients, stakeholders, environments and purpose.

Technology and society

This strand of the curriculum is about recognising that technology and society are inextricably linked; that there is an increasing dependence and therefore vulnerability placed upon us from modern technologies, including those such as embedded systems (Robal, Kann, & Kalja, 2011). A technology in itself may neither be good or bad, but nonetheless it is “purposeful intervention” (Compton & France, 2006, p. 3) by humans so it cannot be completely value free. Technological artefacts thus embody the power and control of the values of the designers (Warschauer, 2004) and their employers, the corporations that regulate design (Feenberg, 2010), through the limits placed upon us by their decisions. In technology education when the judgment of a piece of technology’s fitness for purpose is extended to include all its social implications it is called fitness for purpose in the broadest possible sense.

Embedded systems and society

Embedded systems implicitly embody control over our society as they, for instance, automatically reduce the volume level when we plug headphones into a tablet or phone, operate the lid lock during the spin cycle of a washing machine, determine which DVD zones you can play and when a printer cartridge will automatically wear out; all based upon the preference of designers and not users. It is not inconsequential to society today to have so much unrecognised control everywhere around us. Technology education is about empowering users to appreciate the ‘e-consequences’ on our society of the choices made for us.
In technology education in the past there has been a strong focus on the take-home value of wellcrafted products. As a technology educator I have a strategic reason for take home value in learning about embedded systems. This value is encompassed in the important discussions that students have with stakeholders about their embedded systems technology and a developing awareness of such technologies by the community that the student is a part of.

READ Traditional BPM Life Cycle

Summary of why embedded systems should be taught.

Much research has gone into establishing a national curriculum that guides education to help students become the best possible contributors to our society; and much research has also gone into abstracting what technologists do and building a curriculum for technology students that reflects technological processes. The goal with this section has not been to present embedded systems learning simply as congruent with the curriculum, but to realise that the nature of learning in schools must fit with what is taking place in the world; and the goals of education must align with the needs of our technological world. Modern society has technology at its core, especially the ubiquitous and hidden technologies of embedded systems, so secondary school education is made more relevant by addressing this technology.

Embedded systems – what should be taught?

Having established what embedded systems are and how the learning goals of the New Zealand Curriculum and Technology Education align with the technology of embedded systems, the next stage in developing a programme of learning was determining specifics about what should be taught; this took both a short and a long time. The short path was the surface knowledge of the course such as the choices for programming language, development tools and development platforms. This research pertains to the longer path: the on-going pursuit of student understanding, i.e. performance and capability. The bi-modal nature of these two paths aligns with my own growth from beginning teacher to a more experienced one, and typifies the learning journey from “ignorant certainty to intelligent confusion” (Felder & Brent, 2004a, p. 269).

Chapter 1. Te wero – (the challenge)
Chapter 2. Embedded systems and learning
2.1. Identity – what are embedded systems?
2.2. Why should embedded systems be taught in schools?
2.3. Embedded systems – what should be taught?
2.4. Summary
Chapter 3. How best can embedded systems be learnt?
3.1. What works best
3.2. Deductive and inductive teaching
3.3. Students as participatory learners
3.4. Use of real hardware in embedded systems learning
3.5. Conceptual models and visualisation as learning tools
3.6. Summary
Chapter 4. Classroom action research on visualisation
Chapter 5. Extending System Designer with the visualiser
5.1. The existing learning capabilities of System Designer
5.2. Analysis criteria for existing visualisers
5.3. Summary of features
5.4. Visualiser design decisions
5.5. Extensibility
5.6. Summary
Chapter 6. Visualiser support materials development
Chapter 7. Research methodology
Chapter 8. Results
Chapter 9. Discussion
Chapter 10. Summary
References
Glossary