Real-time systems are systems whose specifications include both logical and temporal correctness requirements. They must produce outputs at the right time in addition to producing logically correct outputs. Many embedded systems are real-time systems. Real-time systems have characteristics like being event-driven, having high failure costs, requiring concurrency and reliability. They can be hard real-time systems where all deadlines must be met or soft real-time systems where some missed deadlines are allowed. Real-time operating systems help manage resources and priorities to meet the timing constraints of real-time applications.
a comprehensive slide on Embedded System.pptxMohanAhmed3
An embedded system is a microprocessor-based computer hardware system with software that is designed to perform a dedicated function, either as an independent system or as a part of a large system. At the core is an integrated circuit designed to carry out computation for real-time operations.
1. Embedded systems are computer systems designed to perform dedicated functions within larger mechanical or electrical systems, with software embedded in the hardware.
2. Hardware and software must be designed together in embedded systems. Key considerations include partitioning tasks between hardware and software, hardware design for low power and real-time needs, and software design for modularity, reusability, and real-time guarantees.
3. Real-time systems, including both soft and hard real-time systems, must guarantee response to external events within specified times to avoid glitches or catastrophic failures. The choice of hardware, software, and real-time operating system depends on these timing requirements.
The document discusses embedded computing systems and outlines some key points:
- Embedded systems are part of larger systems that perform specific functions in constrained, reactive environments using a combination of hardware and software.
- They have real-time requirements and challenges include high complexity, distributed networks, and meeting deadlines with increasing functionality.
- Embedded systems come in many forms, from automotive and industrial control systems to wireless sensor networks and systems within the human body.
The document discusses the evolution of operating systems from simple batch systems to modern systems. Early batch systems used control cards to run jobs sequentially while multiprogramming systems allowed multiple jobs to reside in memory simultaneously. Time-sharing systems provided interactive use through rapid switching between programs. Modern systems include personal computers, parallel and distributed systems, and specialized real-time systems.
This document discusses real-time and embedded systems. It defines embedded systems as computer systems that perform specific functions and often interact with their environment. Real-time systems are systems where the correctness depends on both the logical results and the time the results are produced. Examples of real-time embedded systems include nuclear reactor control and flight control systems. The document discusses characteristics of real-time systems like being event-driven, having high failure costs, and requiring predictable behavior. It also defines types of real-time systems like hard, soft, and firm real-time systems.
High-performance computing (HPC) involves solving complex problems using computer modeling, simulation, and analysis that require huge computational resources beyond what a typical personal computer can handle. HPC is used across many fields including engineering, science, weather prediction, and more. While proprietary supercomputers were once common, HPC has increasingly moved to using commodity computer clusters connected by fast networks due to their affordability, efficiency, and scalability. Clusters now represent over 80% of the world's most powerful supercomputers. HPC simulations are critical across industries by enabling faster product development, more accurate predictions, and accelerating research.
High-performance computing (HPC) involves solving complex problems using computer modeling, simulation, and analysis that require huge computational resources beyond what a typical personal computer can handle. HPC is used across many fields including engineering, science, weather prediction, and more. While proprietary supercomputers were once common, HPC has increasingly moved to using commodity computer clusters connected by fast networks due to their affordability, efficiency, and scalability. Clusters now represent over 80% of the world's most powerful supercomputers. HPC simulations can significantly reduce product development timelines and costs across many industries.
Real-time systems are systems whose specifications include both logical and temporal correctness requirements. They must produce outputs at the right time in addition to producing logically correct outputs. Many embedded systems are real-time systems. Real-time systems have characteristics like being event-driven, having high failure costs, requiring concurrency and reliability. They can be hard real-time systems where all deadlines must be met or soft real-time systems where some missed deadlines are allowed. Real-time operating systems help manage resources and priorities to meet the timing constraints of real-time applications.
a comprehensive slide on Embedded System.pptxMohanAhmed3
An embedded system is a microprocessor-based computer hardware system with software that is designed to perform a dedicated function, either as an independent system or as a part of a large system. At the core is an integrated circuit designed to carry out computation for real-time operations.
1. Embedded systems are computer systems designed to perform dedicated functions within larger mechanical or electrical systems, with software embedded in the hardware.
2. Hardware and software must be designed together in embedded systems. Key considerations include partitioning tasks between hardware and software, hardware design for low power and real-time needs, and software design for modularity, reusability, and real-time guarantees.
3. Real-time systems, including both soft and hard real-time systems, must guarantee response to external events within specified times to avoid glitches or catastrophic failures. The choice of hardware, software, and real-time operating system depends on these timing requirements.
The document discusses embedded computing systems and outlines some key points:
- Embedded systems are part of larger systems that perform specific functions in constrained, reactive environments using a combination of hardware and software.
- They have real-time requirements and challenges include high complexity, distributed networks, and meeting deadlines with increasing functionality.
- Embedded systems come in many forms, from automotive and industrial control systems to wireless sensor networks and systems within the human body.
The document discusses the evolution of operating systems from simple batch systems to modern systems. Early batch systems used control cards to run jobs sequentially while multiprogramming systems allowed multiple jobs to reside in memory simultaneously. Time-sharing systems provided interactive use through rapid switching between programs. Modern systems include personal computers, parallel and distributed systems, and specialized real-time systems.
This document discusses real-time and embedded systems. It defines embedded systems as computer systems that perform specific functions and often interact with their environment. Real-time systems are systems where the correctness depends on both the logical results and the time the results are produced. Examples of real-time embedded systems include nuclear reactor control and flight control systems. The document discusses characteristics of real-time systems like being event-driven, having high failure costs, and requiring predictable behavior. It also defines types of real-time systems like hard, soft, and firm real-time systems.
High-performance computing (HPC) involves solving complex problems using computer modeling, simulation, and analysis that require huge computational resources beyond what a typical personal computer can handle. HPC is used across many fields including engineering, science, weather prediction, and more. While proprietary supercomputers were once common, HPC has increasingly moved to using commodity computer clusters connected by fast networks due to their affordability, efficiency, and scalability. Clusters now represent over 80% of the world's most powerful supercomputers. HPC simulations are critical across industries by enabling faster product development, more accurate predictions, and accelerating research.
High-performance computing (HPC) involves solving complex problems using computer modeling, simulation, and analysis that require huge computational resources beyond what a typical personal computer can handle. HPC is used across many fields including engineering, science, weather prediction, and more. While proprietary supercomputers were once common, HPC has increasingly moved to using commodity computer clusters connected by fast networks due to their affordability, efficiency, and scalability. Clusters now represent over 80% of the world's most powerful supercomputers. HPC simulations can significantly reduce product development timelines and costs across many industries.
Embedded systems can be categorized based on complexity, cost, purpose, available tools and environment. The main categories are stand-alone embedded systems, real-time embedded systems, networked information appliances, and mobile devices. Stand-alone systems take inputs, process them, and produce outputs without connecting to other systems. Real-time systems must perform tasks within strict time deadlines. Networked information appliances are connected to networks like the Internet and can communicate with other nodes. Mobile devices are portable embedded systems.
Resource Management in (Embedded) Real-Time Systemsjeronimored
Rate monotonic analysis provides techniques for analyzing real-time systems with periodic tasks. It focuses on ensuring tasks meet deadlines through priority-based scheduling, where the highest priority is given to the task with the shortest period. The utilization bound test determines if a set of periodic tasks will always meet deadlines based on the total utilization being below a limit that depends on the number of tasks.
This document discusses operating system structures and components. It describes four main OS designs: monolithic systems, layered systems, virtual machines, and client-server models. For each design, it provides details on how the system is organized and which components are responsible for which tasks. It also discusses some advantages and disadvantages of the different approaches. The document concludes by explaining how client-server models address issues with distributing OS functions to user space by having some critical servers run in the kernel while still communicating with user processes.
The document discusses different types of operating systems, including simple batch systems, multiprogramming batch systems, time-sharing systems, personal computer systems, parallel systems, real-time systems, and distributed systems. It provides definitions and examples of operating system concepts like resource allocation, control programs, and kernels. It also describes the evolution of operating systems and migration of concepts between different system types.
A Study Of Real-Time Embedded Software Systems And Real-Time Operating SystemsRick Vogel
This document summarizes a seminar report on real-time embedded software systems and real-time operating systems. It discusses what embedded systems and real-time systems are, and describes some of the key components and requirements of real-time operating systems including multi-tasking, memory management, task scheduling, and case studies of several popular RTOSs. The report aims to provide an overview of the technologies behind embedded systems design and survey available real-time operating systems.
The document provides an overview of embedded system design components and processes. It discusses fabless hardware design including VLSI design tools and flows. It also describes board level design considerations and software design flows for different hardware platforms like FPGA/SOC, programmable DSP/SOC, and reconfigurable architectures. The key steps involved in algorithm design, simulation, synthesis, physical design, fabrication and board testing are outlined.
This document provides an introduction and overview of embedded systems and embedded system design. It discusses the following key points in 3 sentences:
1. It defines embedded systems and lists their essential components as well as characteristics including low cost, low power usage, and small size.
2. It discusses the requirements of embedded microcontroller cores including memory, ports, timers, interrupts, and serial data transfer standards to interface with real-world peripherals.
3. It also covers embedded programming, real-time operating systems, example applications, and textbooks on embedded systems design.
1) Embedded systems are computer systems designed to perform dedicated functions within larger mechanical or electrical systems, often with real-time computing constraints.
2) Hardware platforms for embedded systems include microcontrollers optimized for control applications, digital signal processors for data-intensive applications, and programmable hardware or ASICs.
3) System specialization is important for embedded systems, through techniques like application-specific instruction sets, optimized memory architectures, and heterogeneous registers. This improves properties like performance, power efficiency, and predictability.
The document provides information about real-time systems and real-time operating systems (RTOS). It defines a real-time system as one where the correctness depends not only on logical results but also the time when results are delivered. An RTOS is designed to meet the strict timing constraints of real-time applications through features like multitasking, interrupt handling, and predictable scheduling. Key considerations for selecting an RTOS include its real-time capabilities, footprint, interrupt latencies, available APIs, and development tools.
This document discusses different types of operating systems, including simple batch systems, multiprogramming systems, time-sharing systems, personal computer systems, parallel systems, distributed systems, and real-time systems. It describes the key features of each type of operating system, how they allocate resources and schedule processes, and how operating system concepts have evolved over time to support new hardware architectures and usage models.
The document discusses new trends in embedded systems like mobility, cloud connectivity, and improved user interfaces that require operating systems to adapt. It notes the increasing demand for reliability, safety and security. Real-time embedded operating systems like QNX are better suited than general purpose OSes for applications that have strict availability and reliability requirements due to their deterministic scheduling and memory protection. The document outlines how QNX's microkernel architecture isolates applications and drivers to improve fault containment and system uptime.
This document provides an overview of an operating systems course, including its aims, outline, recommended reading, and introductory content. The key points are:
1. The course aims to explain operating system structure and functions, illustrate concepts with examples, and prepare students for future courses. Students will learn about CPU scheduling, processes, memory management, I/O, protection, and case studies of Unix and Windows.
2. The course outline covers introductions to operating systems, processes and scheduling, memory management, I/O and device management, protection, filing systems, and case studies of Unix and Windows NT.
3. The recommended reading includes textbooks on concurrent systems, operating system concepts, and case studies
RITA SECURE COMMUNICATION PROTOCOL: APPLICATION TO SCADAcsandit
Supervisory control and data acquisition (SCADA) systems have their own constrains and specifications. These systems control many of our critical industrial infrastructures, yet they are hardly secured. The biggest problem in securing these systems is the lack of cryptography support especially that most SCADA systems work in real-time which is not compatible with most cryptography algorithms. Additionally, a SCADA network may include a huge amount of embedded devices with little computational powers which adds to the cost of any security improvement. In this paper we present a new approach that would secure SCADA communications by coding information without the need of the complex cryptography algorithms. The reconfigurable information transmitter agent (RITA) protocol that we present does not need the already installed devices to be modified nor replaced, it only needs to add costless electrical chips to these devices. This approach can also be used to secure any type of communication that respects the protocol's constraints.
The document discusses applications of cyber-physical systems and robotics. Some key areas discussed include smart manufacturing using robotics working safely with humans, transportation systems using vehicle-to-vehicle communication and autonomous vehicles, smart energy grids, infrastructure monitoring using sensors, and medical devices. The integration of computation, networking, and physical processes allows innovative applications that can improve efficiency, safety, reliability and sustainability across many sectors.
Real Time Systems – Issues in Real Time Computing – Structure of a real time system – Process – Task – Threads.
Classification of Tasks – Task Periodicity – Periodic Tasks- Sporadic Tasks – Aperiodic Tasks – Task Scheduling –
Classification of Scheduling Algorithms – Event Driven Scheduling – Rate monotonic scheduling – Earliest deadline first scheduling.
Inter Process Communication:- Shared data problem, Use of Semaphore(s), Priority Inversion Problem and Deadlock Situations -
1. The document discusses the unit ITEL01 - Embedded Systems which covers introduction to embedded computing, instruction sets, textbooks and reference books.
2. It defines what an embedded system is, discusses the hardware and software components, and classification of microprocessors.
3. The document covers advantages of programmable CPUs, functionality of embedded systems, challenges in design, performance aspects, and formalisms for system design including UML.
This document outlines the course content for an Operating Systems class divided into 5 units. Unit I introduces different types of operating systems like batch systems, time-sharing systems, personal computer systems, parallel systems, real-time systems, and distributed systems. It also covers system components, services, and structures. Unit II covers process management, CPU scheduling, and threads. Unit III discusses process synchronization, deadlocks, prevention and avoidance techniques. Unit IV covers memory management techniques like swapping, paging and segmentation as well as virtual memory. Unit V discusses file systems, file attributes, operations, structures and protection as well as mass storage structures.
Real-Time Operating Systems Real-Time Operating Systems RTOS .pptlematadese670
Real-Time OpReal-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operatingv
This document discusses embedded systems. It defines an embedded system as a microprocessor-based system designed to perform dedicated functions. Embedded systems are found in devices ranging from household appliances to spacecraft. The document discusses the history of embedded systems and how they have evolved from using microprocessors to typically using microcontrollers. It also discusses the hardware and software components of embedded systems as well as common programming languages. Examples of different types of embedded systems are provided.
This document discusses embedded systems, including definitions, examples, and key characteristics. It defines an embedded system as a microprocessor-based computer system designed to perform dedicated functions within a larger mechanical or electrical system. Embedded systems are found in devices ranging from household appliances to spacecraft. They are characterized by limited resources, real-time performance requirements, low power consumption, and high reliability. The document also covers embedded system hardware architecture, programming languages, and provides an example of designing a simple temperature measurement system.
Embedded systems can be categorized based on complexity, cost, purpose, available tools and environment. The main categories are stand-alone embedded systems, real-time embedded systems, networked information appliances, and mobile devices. Stand-alone systems take inputs, process them, and produce outputs without connecting to other systems. Real-time systems must perform tasks within strict time deadlines. Networked information appliances are connected to networks like the Internet and can communicate with other nodes. Mobile devices are portable embedded systems.
Resource Management in (Embedded) Real-Time Systemsjeronimored
Rate monotonic analysis provides techniques for analyzing real-time systems with periodic tasks. It focuses on ensuring tasks meet deadlines through priority-based scheduling, where the highest priority is given to the task with the shortest period. The utilization bound test determines if a set of periodic tasks will always meet deadlines based on the total utilization being below a limit that depends on the number of tasks.
This document discusses operating system structures and components. It describes four main OS designs: monolithic systems, layered systems, virtual machines, and client-server models. For each design, it provides details on how the system is organized and which components are responsible for which tasks. It also discusses some advantages and disadvantages of the different approaches. The document concludes by explaining how client-server models address issues with distributing OS functions to user space by having some critical servers run in the kernel while still communicating with user processes.
The document discusses different types of operating systems, including simple batch systems, multiprogramming batch systems, time-sharing systems, personal computer systems, parallel systems, real-time systems, and distributed systems. It provides definitions and examples of operating system concepts like resource allocation, control programs, and kernels. It also describes the evolution of operating systems and migration of concepts between different system types.
A Study Of Real-Time Embedded Software Systems And Real-Time Operating SystemsRick Vogel
This document summarizes a seminar report on real-time embedded software systems and real-time operating systems. It discusses what embedded systems and real-time systems are, and describes some of the key components and requirements of real-time operating systems including multi-tasking, memory management, task scheduling, and case studies of several popular RTOSs. The report aims to provide an overview of the technologies behind embedded systems design and survey available real-time operating systems.
The document provides an overview of embedded system design components and processes. It discusses fabless hardware design including VLSI design tools and flows. It also describes board level design considerations and software design flows for different hardware platforms like FPGA/SOC, programmable DSP/SOC, and reconfigurable architectures. The key steps involved in algorithm design, simulation, synthesis, physical design, fabrication and board testing are outlined.
This document provides an introduction and overview of embedded systems and embedded system design. It discusses the following key points in 3 sentences:
1. It defines embedded systems and lists their essential components as well as characteristics including low cost, low power usage, and small size.
2. It discusses the requirements of embedded microcontroller cores including memory, ports, timers, interrupts, and serial data transfer standards to interface with real-world peripherals.
3. It also covers embedded programming, real-time operating systems, example applications, and textbooks on embedded systems design.
1) Embedded systems are computer systems designed to perform dedicated functions within larger mechanical or electrical systems, often with real-time computing constraints.
2) Hardware platforms for embedded systems include microcontrollers optimized for control applications, digital signal processors for data-intensive applications, and programmable hardware or ASICs.
3) System specialization is important for embedded systems, through techniques like application-specific instruction sets, optimized memory architectures, and heterogeneous registers. This improves properties like performance, power efficiency, and predictability.
The document provides information about real-time systems and real-time operating systems (RTOS). It defines a real-time system as one where the correctness depends not only on logical results but also the time when results are delivered. An RTOS is designed to meet the strict timing constraints of real-time applications through features like multitasking, interrupt handling, and predictable scheduling. Key considerations for selecting an RTOS include its real-time capabilities, footprint, interrupt latencies, available APIs, and development tools.
This document discusses different types of operating systems, including simple batch systems, multiprogramming systems, time-sharing systems, personal computer systems, parallel systems, distributed systems, and real-time systems. It describes the key features of each type of operating system, how they allocate resources and schedule processes, and how operating system concepts have evolved over time to support new hardware architectures and usage models.
The document discusses new trends in embedded systems like mobility, cloud connectivity, and improved user interfaces that require operating systems to adapt. It notes the increasing demand for reliability, safety and security. Real-time embedded operating systems like QNX are better suited than general purpose OSes for applications that have strict availability and reliability requirements due to their deterministic scheduling and memory protection. The document outlines how QNX's microkernel architecture isolates applications and drivers to improve fault containment and system uptime.
This document provides an overview of an operating systems course, including its aims, outline, recommended reading, and introductory content. The key points are:
1. The course aims to explain operating system structure and functions, illustrate concepts with examples, and prepare students for future courses. Students will learn about CPU scheduling, processes, memory management, I/O, protection, and case studies of Unix and Windows.
2. The course outline covers introductions to operating systems, processes and scheduling, memory management, I/O and device management, protection, filing systems, and case studies of Unix and Windows NT.
3. The recommended reading includes textbooks on concurrent systems, operating system concepts, and case studies
RITA SECURE COMMUNICATION PROTOCOL: APPLICATION TO SCADAcsandit
Supervisory control and data acquisition (SCADA) systems have their own constrains and specifications. These systems control many of our critical industrial infrastructures, yet they are hardly secured. The biggest problem in securing these systems is the lack of cryptography support especially that most SCADA systems work in real-time which is not compatible with most cryptography algorithms. Additionally, a SCADA network may include a huge amount of embedded devices with little computational powers which adds to the cost of any security improvement. In this paper we present a new approach that would secure SCADA communications by coding information without the need of the complex cryptography algorithms. The reconfigurable information transmitter agent (RITA) protocol that we present does not need the already installed devices to be modified nor replaced, it only needs to add costless electrical chips to these devices. This approach can also be used to secure any type of communication that respects the protocol's constraints.
The document discusses applications of cyber-physical systems and robotics. Some key areas discussed include smart manufacturing using robotics working safely with humans, transportation systems using vehicle-to-vehicle communication and autonomous vehicles, smart energy grids, infrastructure monitoring using sensors, and medical devices. The integration of computation, networking, and physical processes allows innovative applications that can improve efficiency, safety, reliability and sustainability across many sectors.
Real Time Systems – Issues in Real Time Computing – Structure of a real time system – Process – Task – Threads.
Classification of Tasks – Task Periodicity – Periodic Tasks- Sporadic Tasks – Aperiodic Tasks – Task Scheduling –
Classification of Scheduling Algorithms – Event Driven Scheduling – Rate monotonic scheduling – Earliest deadline first scheduling.
Inter Process Communication:- Shared data problem, Use of Semaphore(s), Priority Inversion Problem and Deadlock Situations -
1. The document discusses the unit ITEL01 - Embedded Systems which covers introduction to embedded computing, instruction sets, textbooks and reference books.
2. It defines what an embedded system is, discusses the hardware and software components, and classification of microprocessors.
3. The document covers advantages of programmable CPUs, functionality of embedded systems, challenges in design, performance aspects, and formalisms for system design including UML.
This document outlines the course content for an Operating Systems class divided into 5 units. Unit I introduces different types of operating systems like batch systems, time-sharing systems, personal computer systems, parallel systems, real-time systems, and distributed systems. It also covers system components, services, and structures. Unit II covers process management, CPU scheduling, and threads. Unit III discusses process synchronization, deadlocks, prevention and avoidance techniques. Unit IV covers memory management techniques like swapping, paging and segmentation as well as virtual memory. Unit V discusses file systems, file attributes, operations, structures and protection as well as mass storage structures.
Real-Time Operating Systems Real-Time Operating Systems RTOS .pptlematadese670
Real-Time OpReal-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operating Systems Real-Time Operatingv
This document discusses embedded systems. It defines an embedded system as a microprocessor-based system designed to perform dedicated functions. Embedded systems are found in devices ranging from household appliances to spacecraft. The document discusses the history of embedded systems and how they have evolved from using microprocessors to typically using microcontrollers. It also discusses the hardware and software components of embedded systems as well as common programming languages. Examples of different types of embedded systems are provided.
This document discusses embedded systems, including definitions, examples, and key characteristics. It defines an embedded system as a microprocessor-based computer system designed to perform dedicated functions within a larger mechanical or electrical system. Embedded systems are found in devices ranging from household appliances to spacecraft. They are characterized by limited resources, real-time performance requirements, low power consumption, and high reliability. The document also covers embedded system hardware architecture, programming languages, and provides an example of designing a simple temperature measurement system.
Batteries -Introduction – Types of Batteries – discharging and charging of battery - characteristics of battery –battery rating- various tests on battery- – Primary battery: silver button cell- Secondary battery :Ni-Cd battery-modern battery: lithium ion battery-maintenance of batteries-choices of batteries for electric vehicle applications.
Fuel Cells: Introduction- importance and classification of fuel cells - description, principle, components, applications of fuel cells: H2-O2 fuel cell, alkaline fuel cell, molten carbonate fuel cell and direct methanol fuel cells.
Harnessing WebAssembly for Real-time Stateless Streaming PipelinesChristina Lin
Traditionally, dealing with real-time data pipelines has involved significant overhead, even for straightforward tasks like data transformation or masking. However, in this talk, we’ll venture into the dynamic realm of WebAssembly (WASM) and discover how it can revolutionize the creation of stateless streaming pipelines within a Kafka (Redpanda) broker. These pipelines are adept at managing low-latency, high-data-volume scenarios.
DEEP LEARNING FOR SMART GRID INTRUSION DETECTION: A HYBRID CNN-LSTM-BASED MODELgerogepatton
As digital technology becomes more deeply embedded in power systems, protecting the communication
networks of Smart Grids (SG) has emerged as a critical concern. Distributed Network Protocol 3 (DNP3)
represents a multi-tiered application layer protocol extensively utilized in Supervisory Control and Data
Acquisition (SCADA)-based smart grids to facilitate real-time data gathering and control functionalities.
Robust Intrusion Detection Systems (IDS) are necessary for early threat detection and mitigation because
of the interconnection of these networks, which makes them vulnerable to a variety of cyberattacks. To
solve this issue, this paper develops a hybrid Deep Learning (DL) model specifically designed for intrusion
detection in smart grids. The proposed approach is a combination of the Convolutional Neural Network
(CNN) and the Long-Short-Term Memory algorithms (LSTM). We employed a recent intrusion detection
dataset (DNP3), which focuses on unauthorized commands and Denial of Service (DoS) cyberattacks, to
train and test our model. The results of our experiments show that our CNN-LSTM method is much better
at finding smart grid intrusions than other deep learning algorithms used for classification. In addition,
our proposed approach improves accuracy, precision, recall, and F1 score, achieving a high detection
accuracy rate of 99.50%.
A review on techniques and modelling methodologies used for checking electrom...nooriasukmaningtyas
The proper function of the integrated circuit (IC) in an inhibiting electromagnetic environment has always been a serious concern throughout the decades of revolution in the world of electronics, from disjunct devices to today’s integrated circuit technology, where billions of transistors are combined on a single chip. The automotive industry and smart vehicles in particular, are confronting design issues such as being prone to electromagnetic interference (EMI). Electronic control devices calculate incorrect outputs because of EMI and sensors give misleading values which can prove fatal in case of automotives. In this paper, the authors have non exhaustively tried to review research work concerned with the investigation of EMI in ICs and prediction of this EMI using various modelling methodologies and measurement setups.
International Conference on NLP, Artificial Intelligence, Machine Learning an...gerogepatton
International Conference on NLP, Artificial Intelligence, Machine Learning and Applications (NLAIM 2024) offers a premier global platform for exchanging insights and findings in the theory, methodology, and applications of NLP, Artificial Intelligence, Machine Learning, and their applications. The conference seeks substantial contributions across all key domains of NLP, Artificial Intelligence, Machine Learning, and their practical applications, aiming to foster both theoretical advancements and real-world implementations. With a focus on facilitating collaboration between researchers and practitioners from academia and industry, the conference serves as a nexus for sharing the latest developments in the field.
A SYSTEMATIC RISK ASSESSMENT APPROACH FOR SECURING THE SMART IRRIGATION SYSTEMSIJNSA Journal
The smart irrigation system represents an innovative approach to optimize water usage in agricultural and landscaping practices. The integration of cutting-edge technologies, including sensors, actuators, and data analysis, empowers this system to provide accurate monitoring and control of irrigation processes by leveraging real-time environmental conditions. The main objective of a smart irrigation system is to optimize water efficiency, minimize expenses, and foster the adoption of sustainable water management methods. This paper conducts a systematic risk assessment by exploring the key components/assets and their functionalities in the smart irrigation system. The crucial role of sensors in gathering data on soil moisture, weather patterns, and plant well-being is emphasized in this system. These sensors enable intelligent decision-making in irrigation scheduling and water distribution, leading to enhanced water efficiency and sustainable water management practices. Actuators enable automated control of irrigation devices, ensuring precise and targeted water delivery to plants. Additionally, the paper addresses the potential threat and vulnerabilities associated with smart irrigation systems. It discusses limitations of the system, such as power constraints and computational capabilities, and calculates the potential security risks. The paper suggests possible risk treatment methods for effective secure system operation. In conclusion, the paper emphasizes the significant benefits of implementing smart irrigation systems, including improved water conservation, increased crop yield, and reduced environmental impact. Additionally, based on the security analysis conducted, the paper recommends the implementation of countermeasures and security approaches to address vulnerabilities and ensure the integrity and reliability of the system. By incorporating these measures, smart irrigation technology can revolutionize water management practices in agriculture, promoting sustainability, resource efficiency, and safeguarding against potential security threats.
Electric vehicle and photovoltaic advanced roles in enhancing the financial p...IJECEIAES
Climate change's impact on the planet forced the United Nations and governments to promote green energies and electric transportation. The deployments of photovoltaic (PV) and electric vehicle (EV) systems gained stronger momentum due to their numerous advantages over fossil fuel types. The advantages go beyond sustainability to reach financial support and stability. The work in this paper introduces the hybrid system between PV and EV to support industrial and commercial plants. This paper covers the theoretical framework of the proposed hybrid system including the required equation to complete the cost analysis when PV and EV are present. In addition, the proposed design diagram which sets the priorities and requirements of the system is presented. The proposed approach allows setup to advance their power stability, especially during power outages. The presented information supports researchers and plant owners to complete the necessary analysis while promoting the deployment of clean energy. The result of a case study that represents a dairy milk farmer supports the theoretical works and highlights its advanced benefits to existing plants. The short return on investment of the proposed approach supports the paper's novelty approach for the sustainable electrical system. In addition, the proposed system allows for an isolated power setup without the need for a transmission line which enhances the safety of the electrical network
1. ECE 720T5 Fall 2011
Cyber-Physical Systems
Rodolfo Pellizzoni
2. / 89
Today’s Outline
1. Introduction to CPS
2. (Detailed) Course Overview
3. Break! Please fill in the survey forms
4. Course Organization
5. Intro to Real-Time Systems (first part – if we have time).
Slides will be available on line (in fact, slides are meant as a
reference, so they are fairly wordy).
2
4. / 89
Embedded Systems
• Embedded system: computing systems designed for a
specific purpose.
• Embedded systems are everywhere!
4
5. / 89
Embedded Systems and the Market
• Quiz: what percentage of today’s current CPU shipment if
destined to PC?
• Answer: less than 0.1%.
• In fact, embedded processor shipments surpassed PCs
back in 1998.
5
6. / 89
Embedded Systems are getting more complex
• Modern high-end cars have over
one hundred processors.
• Increasing number of sensors,
actuators, smart control, GUI..
• Intelligent data fusion.
F-35 Lightning II
Helmet Mounted Display System
Optical Track.
7. / 89
… are more Interconnected
• Command-and-control
network – real-time
integration of vehicles,
people, command.
• Geotagging: useful or
scary?
7
+
• Many other examples
– Power Grid
– Medical systems
– Transportation
– Etc.
8. / 89
CPS – the next evolution
• Cyber-physical systems: integration of computation with
physical processes.
• Still build on top of embedded computing systems.
• Interaction with the physical environment is promoted to
a “first class citizen”.
• Promotes interaction and integration of subsystems
– Classic safety-critical embedded systems: black
boxes
– CPS: white-boxes, open protocols
• Main goals:
– Co-design the cyber and physical part of the system
– Engineer a “system of systems” 8
9. / 89
CPS applications
• Several new application only possible thanks to the CPS
revolution!
9
• Integrated operating room:
seemingly connect medical
devices, plug-and-play
functionality
– Currently: a cable mess
• Smart power grid: predict and
response to varying conditions in
supply and demand of power.
• An other ignored requirement for
sustainable energy…
10. / 89
CPS applications
• Other application are an evolution of existing systems.
10
Unmanned Arial Vehicles
Autonomous Vehicles
11. / 89
CPS Requirements
1. Safety
– All such systems interact with the environment.
– System failure can have catastrophic consequences.
– System correctness depends on both logical results
and the time at which results are produced (real-time).
2. Performance
– Safety is number#1 requirement, but we still need to
achieve sufficient performance.
– Many systems are resource constrained (in either
weight, power, cost, etc.)
3. Interoperability
– Individual subsystems connected by open protocols.
11
12. / 89
CPS as multidisciplinary approach
• Within ECE, CPS design requires competences in…
– Computer Architecture
– CAD & Embedded Design
– Software Engineering
– Control
– Formal Verification
– Real-Time Analysis
• … plus whatever engineering field(s) are related to the
design of the plant/actuator.
• Problem: all such field and subfields have very different
design & development conventions.
• Perhaps we need a new science of CPS design?
12
13. / 89
CPS Challenges – Design Abstractions
• We could argue that the biggest design challenge is in
abstractions – the entire ECE design is a stack-based
process.
13
(from Prof. Edward Lee)
• Unfortunately, most such
abstractions do not directly
encapsulate characteristics
of the environment such as:
– Concurrency
– Criticality
– Timing
• It is very hard to predict if
the cyber part will meet the
requirements of the
physical part!
14. / 89
Current Design Flow
• The picture below exemplifies a typical design flow for an
avionic subsystem.
• Analysis is required to verify that requirements are met.
• Analysis can only be performed after implementation.
• Recipe for disaster!
14
15. / 89
Reliable CPS: not so much!
• In 2007, 12 F-22s
were going from
Hawaii to Japan.
• After crossing the IDL,
all 12 experienced
multiple crashes.
– No navigation
– No fuel subsystems
– Limited
communications
– Rebooting didn’t
help
• F-22 has 1.7 million
lines of code.
F-22 Raptor
16. / 89
CPS Challenges - Safety
• Safety is hard to guarantee in interconnected and
interdependent systems.
1. Do not trust communication channels.
– Ex: medical plug-and-play initiative is looking to
interconnect medical devices using wireless technology.
– Problem: what happens if somebody jams the signal?
– Each subsystem must be independently safe.
2. Do not trust the users.
– Users are an (unfortunate) part of the systems.
– Users are very error prone: over 90% of avionic
accidents are caused by flight crew/controllers.
– System must be protected against user mistakes
16
17. / 89
CPS Challenges - Safety
3. Do not trust lower-criticality subsystems.
– Medical pacemaker composed of multiple subsystems.
– Life-critical functionalities: base pacing, wiring, battery
– Non-critical functionalities: adaptive pacing, logging,
programming, RF communication.
– Protect life-critical subsystem.
17
Pacemaker
18. / 89
Verification & Certification
• How do we ensure safety?
1. Formal Verification
– Build a model of the systems.
– Prove (mathematically) that the system satisfies some
safety property.
– Problem#1: no good model for the whole system.
– Problem#2: model is not implementation.
2. Certification
– Usually a process-based mechanism: show that you
have performed all process step according to some
standard (ex: DO178a/b/c, IEC 61508).
– Typically includes extensive testing.
– Very expensive. 18
19. / 89
CPS Challenges - Integration
• Putting the system together is much more challenging that
implementing the individual subsystems.
• Quiz (avionic systems): can you guess what % of $ goes in
implementation vs debugging?
19
20%
Implementation
80%
Debugging &
Verification
Avionic Development Cost
• Individual productivity for
safety-critical code is
reported as 6 lines/day!
– F22: 1.7 million lines / 6 =
776 man-years
– Perhaps the US$66.7billion
program cost is not a
surprise…
• Clearly the design process
must be improved…
20. / 89
CPS Challenges - Timing Predictability
• The biggest architectural challenge.
• The lowest abstraction layer (transistors)
is pretty deterministic – we know how to
compute exact timings.
• However, higher levels lose all concept
of timing.
– Deep pipelining, caches, out-of-order
and speculative execution…
– Thread models, locking, interrupts…
• This is fine for general purpose
computing, but not for CPS – the
physical system uses real time!
20
(by Prof. Edward Lee)
21. / 89
CPS Challenges - Timing Predictability
• We need to ensure that computation
always finishes within guarantee time
windows -> We are interested in worst-
case performance, not average
performance!
• Timing predictability
– The time that the system requires to
perform an operation should exhibit
little variation
– Such time should be easy to compute
– It should not be affected by other
parallel operations in the system.
21
(by Prof. Edward Lee)
22. / 89
Real-Time and Composability
• System correctness depends on:
– Logical correctness: system produces correct results.
– Temporal correctness: system produces results at the
right time.
• Timing (real-time) analysis = verify temporal correctness.
• Ideally, we want composable analysis
– Verify each subsystem in isolation
– Then verify that there interaction is correct
• Unfortunately, this is very hard in practice…
• Main issue: hardware and software resources shared
among multiple subsystems.
22
23. / 89
Ex: Memory and Composability Issues
• Consider a dual-core system where last-level cache is shared
among the cores.
• We run two virtual machines, each on one core. VM#A is
safety critical, VM#B is not.
• If VM#B suffers a cache miss, it can replace a cache line of
VM#A in last-level cache
– Result: VM#B delays VM#A.
– Criticality-inversion: the safety of VM#A depends on VM#B
• Plenty of other examples in modern architecture!
– Main memory
– I/O data transfers
– Interrupts
– Etc. 23
24. / 89
COTS Components
• So why don’t we use more predictable components?
• Partially a performance problem.
• Commercial-Off-The-Shelf (COTS) components are often
much faster than components designed for safety-critical
systems.
– Ex: avionic SAFEbus: 60 Mbit/s
– PCI Express 3.0: over 16Gbyte/s
• Unfortunately, these hardware components are not
designed to provide predictable performance.
25. / 89
Transaction
Length
Bandwidth
(256B)
No interference 596MB/s (100%)
128 bytes 441MB/s (74%)
256 bytes 346MB/s (58%)
512 bytes 241MB/s (40%)
COTS example: Bus Arbitration
• Two DMA peripherals transmitting at
full speed on PCI-X bus.
• Round-robin arbitration does not
allow timing guarantees.
CPU
RAM
26. / 89
What is Required - Isolation
• Isolation: one subsystem should not affect another
unrelated subsystem.
• Current architectures are pretty good at logical isolation…
– Ex: memory protection and privilege levels in the CPU
make sure that a process can not mess with the
memory of another process or the OS.
• … but fairly poor at temporal isolation.
• Note #1: any and all hw isolation mechanisms are useless
if not supported by the OS.
• Note #1: after the first OS was created, it took a while
before hw architects started implementing protection
mechanisms. So we stand a chance!
26
27. / 89
CPS Challenges – Software Models
• Current software programming models and languages are
inadequate to support CPS design.
• C is by far the most popular language for embedded sys.
• C has no intrinsic support for concurrency, timing parameters,
synchronization, etc.
• POSIX libraries (ex: threads) are often used, but again lack any
explicit concept of timing.
• Extremely common operations in controller implementation:
– specify that I want to execute an operation after a given
amount of time
– specify that I want to complete an operation within a given
amount of time
• Why do I need to use OS constructs (times, watchdogs) for this?
27
28. / 89
What the course is about
• Focus#1: provide an understanding of the challenges in
CPS design
– CPS as an interdisciplinary field
– Specialize in one aspect, but understand the big picture
• Focus#2: provide an understanding of the state-of-the-art
solutions in architectures for CPS systems.
• In particular we will focus on:
– Predictable computer architectures (largest portion of
the course)
– Related Operating System support
– Timing analysis techniques
28
29. / 89
What the course is about
• If you are doing research in any of the (general fields) of:
– Computer architecture
– Operating systems
the course will provide you with an appreciation of the
specific techniques required for safety-critical embedded
systems.
• If you are doing research in control systems, the course will
provide you with an appreciation of “what sits behind” and
why the various parts of the system should be co-designed.
• If you are specifically interested in safety-critical embedded
systems, the course will provide an overview of the state-
of-the-art in the field of embedded architectures and what is
to come next.
29
30. / 89
What we are not going to cover
• We will not cover in details:
• Control theory: while modeling the physical part of the system is
integral to CPS design, this is not a course on control.
• Real-Time schedulability theory: CPS systems are real-time
systems, so we will provide an overview of related topic. If you
are interested in real-time theory, consider ECE750T22.
• Embedded software design: software application models are
covered in ECE750T22. We are interested in sw/hw interactions.
• Networking: CPS are usually networked systems, but we will
focus on node-level architecture.
30
32. / 89
Why an overview?
• Three main reasons:
1. All topics are interrelated - understanding the big picture
helps following each individual topic
2. It gives you a better idea about the scope of the course
(and possible project ideas)!
3. It let me better calibrate the course based on your
interests and background.
32
33. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
33
34. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
– This lecture!
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
34
35. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
– Not the focus of the course, but required for students
without relevant background.
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
35
36. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
– A more detailed look at specific examples of CPS
systems and related challenges.
– I will focus on avionics and automotive systems, with
additional examples from other fields.
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
36
37. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
37
38. / 89
3. Predictable Computer Architecture
• What we need:
– Timing Predictability
– Isolation
• What we are going to see: how our computer architecture
design must change to accommodate such requirements.
• This involves all main components of the architecture:
– Pipeline (and other elements of the core)
– Caches
– Interconnects
– Memory controllers
– I/O Peripherals
38
39. / 89
Re-design vs Modification vs Analysis?
• There basic ways to achieve our objectives:
1. Analysis
– Do not modify the system. Instead, analyze it for safe
performance bounds (worst-case).
– Problem #1: not composable. Analysis typically relies on
exact information on all components (sw/hw) in the system.
– Problem #2: worst-case performance bounds can be pretty
bad.
– Cache is a typical example – if we can not compute the exact
cache state, then using cache actually leads to decreased
performance in the worst-case.
• If we cannot be sure about the cache state, each access
can be a cache miss -> in the worst-case each access
causes a write-back and a fetch.
39
40. / 89
Re-design vs Modification vs Analysis?
2. Modify the architecture
– The complexity of changing different portions of the
architecture is not the same!
– Core redesign: very expensive
– Interconnects/memory architecture: done all the type.
– Main idea: leave the core as-is. Adapt the rest to support
more predictable performance.
• Ex: ARM System-on-Chips
– Companies license either hard IP core (gate netlist) or soft IP
core (Verilog) from ARM.
– Then they assemble the rest of the SoC.
– Highly competitive market in the consumer area (ex:
smartphone SoC by Samsung, Qualcom, TI, NVIDIA…)
40
41. / 89
Re-design vs Modification vs Analysis?
• Ex: Freescale produces PowerPC-based SoCs.
– Only two (currently) core models: e500mc and e600.
– Tens of different SoCs.
– Some SoCs are specialized for embedded architectures.
41
42. / 89
Re-design vs Modification vs Analysis?
3. Redesign the architecture
• Main concept: current architectural paradigm does not work for
CPS.
– No implicit concept of time.
– Only cares about average performance, not worst-case
performance.
• Therefore: change the architectural paradigm!
• Challenge: built a fully-predictable machine but do not sacrifice
(too much) performance.
• Complete redesign means it is much harder to sell to industry
– CPS market is currently smaller than non-critical embedded
systems (i.e. consumer market)
– No IP reuse means little economy of scale (at the moment)
– You will not see this in products for quite some time.
42
43. / 89
Re-design vs Modification vs Analysis?
• Several very interesting research projects…
43
PRecision Timed Machine (Berkeley)
Predictable Scratchpads (York)
Predator DRAM controller (NXP)
44. / 89
Memory architectures
• Memory wall problem: cpu speed (in the past) / number of cores
(in the present/future) increases faster than memory bandwidth.
• Caches are required to bridge the gap, but shared caches are
inherently unpredictable.
– Allocation interference: one application can evict cache lines
of another application
– Timing interference: two cores try to access the same cache
bank at the same time.
• Solutions?
– Smart allocation/replacement schemes
– Cache partitioning
– Do not share caches among cores (counterintuitive)!
44
45. / 89
Memory architectures
• More solutions? - Scratchpad
memories
• A programmable cache
• Software is responsible for
loading/unloading the scratchpad
• Writing applications without OS/
compiler support becomes harder
– Non-transparent mechanism
– Main issue: pointers.
• (Partial) solutions:
– Scratchpad MMU
– Allocation algorithms
• Currently used in Sony PS3
(CellBE processor)
45
Sony/IBM/Toshiba CellBE processor
46. / 89
Memory controllers
• Even with caches, main memory can easily become a
bottleneck in multicores
• What limits memory bandwidth?
• Essentially: number of available pins on the package.
Current fabrication processes have troubles integrating
high-density memory (DRAM) with CMOS logic.
• How should be arbitrate access to main memory to provide
predictable performance to all cores?
46
Can you guess the
number of pins?
Solution: 1336
(Intel i7 LGA1336)
47. / 89
Interconnects and I/O
• On-chip bandwidth wall.
– Scalable communication between
cores in a multi-core system
– Networks-on-chip provide
scalability and high-performance
compared to point-to-point or
bus-based solutions
– How can we provide isolation?
• I/O data latency is as important as
core execution latency for control
systems
– How can we arbitrate access to
communication resource between
different peripherals? 47
80 cores connected using an NoC
48. / 89
Heterogeneous Systems
• Modern SoC devices are highly heterogeneous systems -
use the best type of processing element for each job
• Examples:
– GPU
– FPGA
– DSP
– Specialized Processors
• Good for CPS – most of this
processing elements are more
predictable that a CPU!
• Challenge: schedule and
orchestrate computation among all processing units.
48
NVIDIA Tegra 2 SoC
49. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
49
50. / 89
Real-Time OS
• General purpose OS are typically highly unpredictable –
system activity (interrupt handlers, device drivers) can
preempt applications at any time.
• Traditional Real-Time Operating Systems have been
designed to avoid such pitfall. Three main requirements:
1. OS Predictability
2. User Configurability
3. Reliability
50
51. / 89
OS Predictability
• All OS operations are performed at fixed, predetermined
times or within predetermined time intervals
• Examples:
• Time between receiving an event (interrupt) and activating
a process
• Activation jitter for periodic events (i.e. max difference
between expected and measured activation time)
• Context switch
• Time to acknowledge peripheral interrupts
• Time required to execute device drivers in the kernel
51
52. / 89
Example: Interrupt Processing
• Interrupts are the number #1 source of unpredictability
(jitter) in OS.
• Especially problematic in I/O intensive systems – we must
schedule not just processes, but interrupts as well!
• The graph below was obtained on a RTLinux system (quite
sad)!
52
53. / 89
User Configurability
• Kernel must be highly configurable
– Scheduling algorithms, process allocation (if multicore)
– Selecting required OS components
– Manually controlling memory management (ex: locking
pages for real-time tasks)
– Manually controlling I/O algorithms
53
54. / 89
Reliability
• Faults in one portion of the system should not affect the
rest of the system
– Faults in the code of one process should not be allowed
to affect other process
– Faults in one kernel component (ex: driver) should not
bring down the whole kernel
• OS should be able to react to HW faults – degrade
performance rather than shutting down the system
• Key idea: safeguard safety-critical tasks at the cost of low-
criticality tasks
54
55. / 89
New OS Abstractions?
• A predictable hardware architecture is useless if the
operating system does not take advantage of architectural
features.
• We need new OS abstractions to support such features.
• We also need new abstractions to manage the increasing
system complexity of CPS:
– Mixed-criticality systems
– Many-core systems
– Complex resources (memories, I/O, heterogeneous
devices, etc.)
55
56. / 89
Safety Hypervisors
• Simple idea: Virtual Machines for real-time systems
• Complex implementation
– Standard virtual machine only provide logical isolation
– We also need temporal isolation
56
Green Hill INTEGRITY
“Multivisor”
57. / 89
Memory Optimization
• Can the OS helps to alleviate memory bottlenecks?
• Yes! The OS (or hypervisor) controls the allocation and
scheduling of processes onto the various cores
– Also other processing elements for heterogeneous
systems
• Allocation and scheduling must be memory-aware
– Classic example: cache affinity. Try to avoid moving a
process to a core that uses a different cache.
57
58. / 89
OS Organization
• Increasing complexity of physical
resources requires per-application
allocation policies.
• How should the system be
structured to still guarantee
isolation?
• Component-based systems: build
the OS from a collection of
components with well-specified
interfaces.
• This components are typically
hierarchical – parent subsystems
delegate resource allocation and
scheduling to children subsystems.
58
HIRES Hierarchical
Resource Model
59. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and Verification for
CPS.
59
60. / 89
How Timing Analysis Work
• Timing analysis = verify temporal correctness.
• In real-time systems, computation and communication
activities are associated with (absolute) deadlines – latest
possible time by which the activity must complete.
• Real-time schedulability analysis: algorithm that takes a set of
CPU processes (real-time tasks) executed on the same core(s)
as input, and outputs YES if we can guarantee that all tasks
meet their deadline.
• Problem: classic schedulability analysis assumes that the
worst-case execution time of each task is known.
• In practice, computing such worst-case execution time is much
harder than running the schedulability analysis itself…
60
61. / 89
The Worst-Case Execution Time Problem
• How do we compute the worst-case time required to
execute a computation activity (task)?
• How do we compute the worst-case time (latency) required
to complete a communication activity?
• The hardest problem in real-time computing!
• Problem: both depend on the underlying hw architecture
• If the architecture is not predictable, this is a tough
problem!
• If the architecture is predictable, it is still a non-trivial
problem…
– Real applications use multiple resources, and their
interaction must be understood.
61
62. / 89
The Worst-Case Execution Time Problem
• Two main solutions : measurement and static analysis.
• Measurement
– Run the task a lot of times varying inputs and other
conditions that could affect it (ex: state of caches).
– Record the longest measured execution time.
– In reality a bit more complex that this…
– testing all inputs might be impractical, so we need to
carefully select test vectors
– Main issue: only works if we have already implemented
the whole system! Does not help with design
– Still, this is what industry does…
62
63. / 89
The Worst-Case Execution Time Problem
• Static Analysis
– Run a (complex) algorithm that analyzes the task code
and HW architecture and predicts the worst-case.
– This involves analysis:
• Core execution, pipeline, branch prediction, etc.
• Caches
• Interconnects
• Main memory
– Current tools have limitations; still an area of active
research.
– Also requires application code, i.e. implementation.
63
64. / 89
Performance Analysis
• Neither measurement nor static analysis work very well at
the design stage; they are instead useful to verify (also
possibly certify) the final system.
• What can we do at the design stage? How can we know if
the system is correctly dimensioned (i.e. we have enough
resources for the target applications)?
• Main idea: early performance analysis
– Build a (possibly rough) model of the system
– Use it to analyze performance
– We do not need exact numbers, but rather a ballpark
estimation.
64
65. / 89
Performance Analysis
• Ex: Network Calculus and Real-Time Calculus
– Provide a characterization of available system resource
(service curve). Resources can model computation or
communication elements.
– Provide a characterization of requests for system resources
(arrival curve)
– Compute deterministic worst-case delays and buffer sizes
(for communication activities).
• Deterministic vs stochastic analyses
– Deterministic analyses focus on computing worst-case
bounds.
– Stochastic analyses (ex: queuing theory) focus on
probabilistic bounds
– Both are useful – correct use depends on uncertainties
in the model. 65
66. / 89
Course Topics
• More in details, we will cover the following topics:
1. Introduction to CPS
2. Introduction to Real-Time Systems
3. CPS applications
4. Predictable Computer Architecture
5. Predictable OS Abstractions
6. Timing and Performance Analysis
7. Introductions to Models of Computation and
Verification for CPS.
66
67. / 89
Models, Verification, and other topics
• Essentially, everything that we did not cover in the previous
section.
• Subject to change based on time and interests, but we will
(at least briefly) cover some of the main topics.
• How can we model both the cyber and the physical
systems?
• How can we verify the whole system?
67
68. / 89
Architecture Description Languages
• Let’s start by modeling the whole cyber system!
• Several languages have been proposed in the field of
software engineering to describe the architecture of teh
software system. Most famous: UML.
• Problem: UML is really meant for object-oriented sw systems.
• Timing characteristics of CPS software strictly depends on
hw architecture, so we should model that as well.
• Next step: also model the physical system.
– Much more complex: the model of computation of physical
reality (i.e. differential equations) is very different than the one
used for computation (ex: automata, touring machines, etc.)
– More on this later on…
68
69. / 89
Architecture Description Languages
• Ex: AADL (Architecture
Analysis & Design
Language)
• Gaining traction in the
avionic domain
• Models both logical
components (sw) and
physical components (hw)
• Mapping: assign logical to
physical components.
69
70. / 89
Formal Methods and Timing
• Formal Methods can be used to verify system correctness.
• Usually the goal is to model-check the system, or a portion
of the system.
• To be useful in CPS verification, the formal language must
include an explicit knowledge of time.
• Ex: timed automata (UPPAAL model checker)
70
closed guard
reset
Location
Transition
2
a
0
:
a
2
b
0
:
b
1
:
a
0
:
b
A
Clocks: {a,b}
71. / 89
Hybrid Models and Verification
• Most formal languages can only model discrete systems
and events.
• Unfortunately, while reality might indeed be discrete at the
quantum level, people like to model the physical
environment using continuous processes.
• A hybrid model is a model that mixes discrete state with
continuous state.
• Active research on how to verify, control and synthesize…
71
72. / 89
Run-Time Monitoring
• Two issues with formal methods:
– Struggle with verification of very large systems (state-
space explosion)
– Proof is only as good as the model
• Alternative solution: Run-Time Monitoring
– Formally specify safety properties, but not how the
system works.
– At run-time, check system events again the formal
safety specification.
– If a failure is detected, perform recovery
– The monitors can be implemented either in hw or in sw.
– Run-time overhead is a concern.
72
74. / 89
Instructors
• Rodolfo Pellizzoni
• Office: E5 4113
• Email: rpellizz@uwaterloo.ca
• What I study:
– Predictable hardware architecture
– Real-Time Operating Systems
– HW-SW Co-design of safety-critical systems
– System modeling and analysis
74
75. / 89
Lecture Organization
• Lectures will consist of a mix of my presentations,
presentations by students, and paper discussion.
• How this is typically going to work:
– I introduce a topic in the second half of class and give
some paper to read.
– We discuss those papers (and related results) in the first
half of the next class.
• 2-3 papers each week (depending on length/complexity)
• Participation in class discussion is essential!
– This is a grad course; you need to be able to critique
paper content
– It keeps everybody focused (3 hours can be long…)
75
76. / 89
Seminar Presentation
• Students taking the course for credit are required to provide
one formal seminar presentation during the course (in class).
– If you are auditing the course, you are welcomed to give a
non-formal presentation, but are clearly not required.
• Presentation should focus on 1-2 related papers.
• Paper list will be finalized next week (after adjusting the
course content based on people’s interests)
• Your choices:
– Pick your paper from the assigned reading list.
– Pick one of the “extra” papers.
– If you want to cover something else, please talk to me.
76
77. / 89
Seminar Presentation
• Slots will be assigned first-come, first-serve. Please schedule
your slot at least one week in advance.
• What is the goal of the seminar presentation?
– Clearly explain the paper motivation: what problems are the
authors trying to solve?
– Provide an overview of the solution. Focus on:
• How applicable this technique/solution is? Does it have
any major limitations?
• What are the strong points of this approach?
• What are the weak points of this approach?
• How does it relate to everything else we have seen in the
course so far?
77
78. / 89
Website
• Course website is hosted at
http://ece.uwaterloo.ca/~rpellizz/ECE720T5.php
• We will post:
– Assigned papers
– Lecture slides
– Seminar presentations
• Lecture slides will go online some time after the lecture
itself.
78
79. / 89
Course Tracks
• Two different course tracks for evaluation &
assignments.
• Research track
– Strongly suggested for PhD/MASc students.
– More focused on research project
• Applied track
– More structured project option.
– More focused on the course material (and final
exam!)
• Please make a decision by
79
80. / 89
Research Track
• Involves a course project on a topic of the student’s choice
(related to the course content).
• Mark Breakdown:
– Lecture participation: 5%
– Seminar participation: 10%
– Project proposal: 10%
– Project literature review: 15%
– Project presentation: 10%
– Final: 50%
• Project report 25%
• Essay 25%
80
81. / 89
Research Track
• The project should be original and strive to make a new
contribution.
• You are welcomed to come up with your own ideas; I can
also suggest some.
• Bringing ideas from your specific research area in the CPS
domain is a great idea! Diversity is appreciated.
• You can work alone or in a group (max 2-3)
– Project complexity should be proportional to number of
people.
– Responsibility should be clearly defined; all members
should do part of the writing and work on each
assignment.
81
82. / 89
Research Track
• Project proposal
– Max 2 pages document
– Describe what you want to do, why is it relevant, what
will be the contribution, and a brief summary of your
workplan (possibly with group assignments).
– Should be in the form of an extended abstract.
– Due Monday Oct 9 at 8:00AM.
• Project literature review
– At least 2 pages document
– Carefully review and summarize related literature on the
topic.
– Explain how your approach relates to the state-of-the-art
– Due Monday Oct 30 at 8:00AM. 82
83. / 89
Research Track
• Project presentation
– During final lecture
– Each individual/group will have a slot to present his
findings.
– Similar to seminar presentation: stress not just the
technical aspects, but also why your project is cool!
• Project report
– Due on final exam date.
– It should be in the format of a 6 page (or more if
needed) IEEE or ACM conference paper.
– It will be evaluated as a normal conference paper would
be – novelty, presentation, technical content.
83
84. / 89
Research Track
• Format for all project deliverables: IEEE or ACM double-
column conference format.
• I suggest using latex, but that is up to you…
• Final exam
– Open-book final, essay-style
– We will ask you to discuss and possibly apply the results
in one or more related papers discussed in class
84
86. / 89
Applied Track
• Individual project
• Project will not be original – goal is to get you development
experience in a specific CPS subfield.
• Project will be tailored based on your expertise - please fill
the information form and contact me next week so we can
set up a time to discuss it
• General fields you can work on:
– Embedded applications
– System Software
– Hardware Development (FPGA)
– Formal Verification
• Final report due last day of lectures
86
87. / 89
Applied Track
• Closed-book final exam
• It will cover all material in the course
• What you are expected to know:
– The content of the lecture slides in detail
– The key points about each of the assigned papers
– I will not ask you to remember paper proofs or
algorithms in detail (unless otherwise specified)
– If we ask you to apply an algorithm, we will provide you
the corresponding paper during the final
87
88. / 89
Office Hour
• My proposal: Friday 3:00PM-4:00PM. Does that work fine?
• You are welcomed to schedule any other time by email.
• To ensure a prompt answer, use ECE750T5 in the title.
• If you are looking for research ideas for your research
project, please contact me by next week. We will discuss
additional ideas next week.
• Similarly, if you wish to take the applied track, please
contact me soon.
• For individual/groups in the research track, we will
schedule four meetings in even weeks (starting in the week
of Oct 2).
88
89. / 89
Next Week Assignments
• Seminar this Friday:
– Cyber-Physical Systems: A New Multi-Disciplinary
Frontier for Computer Science and Engineering
– Prof. Raj Rajkumar from CMU – worldwide leader in the
CPS revolution
– Davis Center 1302, 11:00AM
– Please plan to attend if you do not have conflicts!
• Papers will be available on the website later today.
89