This document provides an overview of dependability and dependable systems. It defines dependability as the trustworthiness of a system such that reliance can be placed on the service it delivers. The key aspects of dependability discussed include fault prevention, fault tolerance, fault removal, and fault forecasting. Fault tolerance techniques aim to provide service even in the presence of faults through methods like redundancy, error detection, error processing through recovery, and fault treatment. Dependable system design involves assessing risks, adding redundancy, and designing error detection and recovery capabilities.
This document provides an overview of dependability and dependable systems. It defines dependability as an umbrella term that includes reliability, availability, maintainability, and other attributes that allow systems to be trusted. Dependability addresses how systems can continue operating correctly even when faults occur. Key topics covered include fault tolerance techniques, error processing, failure modes, and modeling approaches for analyzing dependability. The goal of the course is to understand how to design systems that can be relied upon to deliver their services as specified, even in the presence of faults or unexpected events.
Dependable Systems -Fault Tolerance Patterns (4/16)Peter Tröger
The document discusses various patterns for achieving fault tolerance in dependable systems. It covers architectural patterns like units of mitigation and error containment barriers. It also discusses detection patterns such as fault correlation, system monitoring, acknowledgments, voting, and audits. Finally, it discusses error recovery patterns like quarantine, concentrated recovery, and checkpointing to avoid data loss during recovery. The patterns provide reusable solutions for commonly occurring problems in building fault tolerant systems.
Dependable Systems - Hardware Dependability with Redundancy (14/16)Peter Tröger
1) The document discusses hardware dependability through the use of redundancy. It provides examples of static redundancy like voting and N-modular redundancy as well as dynamic redundancy using techniques like back-up sparing and duplex systems.
2) IBM's zSeries mainframe computers are highlighted as an example of a highly redundant system, using techniques like machine check handling, error correction codes, unit deletion for degradation, and fully redundant I/O subsystems.
3) Redundancy comes at a cost but can effectively improve reliability through techniques that either mask faults or allow systems to reconfigure around faults. The level of redundancy must be weighed against associated costs and design complexity.
This document provides an overview of dependability and dependable systems. It defines dependability as an umbrella term that includes reliability, availability, maintainability, and other attributes that allow systems to be trusted. Dependability addresses how systems can continue operating correctly even when faults occur. Key topics covered include fault tolerance techniques, error processing, failure modes, and modeling approaches for analyzing dependability. The goal of the course is to understand how to design systems that can be relied upon to deliver their services as specified, even in the presence of faults or unexpected events.
Dependable Systems -Fault Tolerance Patterns (4/16)Peter Tröger
The document discusses various patterns for achieving fault tolerance in dependable systems. It covers architectural patterns like units of mitigation and error containment barriers. It also discusses detection patterns such as fault correlation, system monitoring, acknowledgments, voting, and audits. Finally, it discusses error recovery patterns like quarantine, concentrated recovery, and checkpointing to avoid data loss during recovery. The patterns provide reusable solutions for commonly occurring problems in building fault tolerant systems.
Dependable Systems - Hardware Dependability with Redundancy (14/16)Peter Tröger
1) The document discusses hardware dependability through the use of redundancy. It provides examples of static redundancy like voting and N-modular redundancy as well as dynamic redundancy using techniques like back-up sparing and duplex systems.
2) IBM's zSeries mainframe computers are highlighted as an example of a highly redundant system, using techniques like machine check handling, error correction codes, unit deletion for degradation, and fully redundant I/O subsystems.
3) Redundancy comes at a cost but can effectively improve reliability through techniques that either mask faults or allow systems to reconfigure around faults. The level of redundancy must be weighed against associated costs and design complexity.
What activates a bug? A refinement of the Laprie terminology model.Peter Tröger
The document proposes refinements to the Laprie terminology model for describing software bugs. It introduces concepts of a fault model describing faulty code, a fault condition model describing enabling system states, and an error model describing states where faults are activated and may lead to failures. A failure automaton is presented with states for disabled, dormant, and active faults, as well as detected errors and outages. Events are defined for when fault conditions are fulfilled or no longer fulfilled, faulty code is executed, and failures occur. The refinement aims to separately consider investigated software layers and their environment in order to better describe what activates bugs.
This document discusses fault-tolerant design techniques for real-time systems. It covers fault masking, reconfiguration, redundancy in hardware, software, and information. Specific techniques discussed include majority voting, error correcting memories, reconfiguration through fault detection, location, containment, and recovery. Hardware redundancy approaches like triple modular redundancy are examined, as are software redundancy techniques like N-version programming and recovery blocks.
Fault recovery tactics in software systems include:
- Voting with redundant components to detect and correct faults. Diversity uses different software/hardware to detect algorithm faults.
- Active redundancy keeps redundant components synchronized in real-time, allowing recovery in milliseconds by switching to backups.
- Passive redundancy uses a primary component with backup components that are periodically resynchronized, allowing recovery in seconds.
- Using spare components requires reconfiguring software and state on the spare, increasing recovery time to minutes.
- Other tactics for recovering failed components include running them in shadow mode, resynchronizing their state, and rolling back to checkpoints.
The document discusses software fault tolerance techniques. It begins by explaining why fault tolerant software is needed, particularly for safety critical systems. It then covers single version techniques like checkpointing and process pairs. Next it discusses multi-version techniques using multiple variants of software. It also covers software fault injection testing. Finally it provides examples of fault tolerant systems used in aircraft like the Airbus and Boeing.
Formal verification is the process of proving or disproving properties of a system using precise mathematical methods. It provides guarantees that no simulations will violate specified properties. Formal verification can be applied at the block and system-on-chip levels to eliminate bugs early. However, current formal verification tools have limitations including capacity issues, generating coverage metrics from assertions, and handling large designs and multiple modes of operation. Improving formal verification requires efficient strategies and advancing tool capabilities.
Formal verification involves proving the correctness of algorithms or systems with respect to a formal specification using mathematical techniques. It can be done by formally modeling a system and using theorem proving or model checking to verify that the model satisfies given properties. Theorem proving uses logical deduction to prove properties, while model checking automatically checks all possible states of a finite model against temporal logic properties. Both approaches have advantages and limitations, but formal verification can help find bugs and prove correctness of systems.
This document discusses software testing for embedded systems. It covers different types of testing including unit, integration, system, and acceptance testing. It also discusses testing at different stages of the development lifecycle. Key aspects of testing covered include functional testing, non-functional testing, structural testing, regression testing, and maintenance testing. The goal of testing is to find defects and ensure software quality in terms of functionality, reliability, usability, and other factors.
Fault-tolerant computer systems are designed to continue operating properly even when some components fail. They achieve this through techniques like redundancy, where backup components take over if primary components fail. The document discusses the goals of fault tolerance like ensuring no single point of failure. It provides examples of how fault tolerance is implemented in areas like data storage and outlines techniques used to design and evaluate fault-tolerant systems.
Fault tolerance systems use hardware and software redundancy to continue operating satisfactorily despite failures. They employ techniques like triplication and voting where multiple processors compute the same parameter and vote to ignore suspect values. Duplication and comparison has two processors compare outputs and drop off if disagreement. Self-checking pairs can detect their own errors. Fault tolerant software uses multi-version programming with different teams developing versions, recovery blocks that re-execute if checks fail, and exception handlers.
A fault tolerant system is able to continue operating despite failures in hardware or software components. It gracefully degrades performance as more faults occur rather than collapsing suddenly. The goal is to ensure the probability of total system failure remains acceptably small. Redundancy is a key technique, with hardware redundancy using multiple redundant components and voting on outputs to mask faults. Static pairing and N modular redundancy are two hardware redundancy methods.
The document discusses faults, errors, and failures in systems. A fault is a defect, an error is unexpected behavior, and a failure occurs when specifications are not met. Fault tolerance allows a system to continue operating despite errors. Fault tolerant systems are gracefully degradable and aim to ensure small failure probabilities. Faults can be hardware or software issues. Various failure types and objectives of fault tolerance like availability and reliability are also described.
This document discusses real-time systems and provides an overview of key concepts in two sessions. The first session defines real-time systems, distinguishes between hard and soft real-time categories, and covers design approaches like super-loops and multitasking. The second session defines real-time operating systems, discusses common commercial and free RTOSs, and explains concepts like tasks, kernels, schedulers, preemptive vs. non-preemptive scheduling, and inter-task communication methods.
This document discusses techniques for achieving fault tolerance in systems. It defines key terms like fault, error, failure and describes different types of faults like hardware faults and software faults. It also discusses fault detection methods like online and offline detection. The document covers different approaches to provide redundancy for fault tolerance like hardware, software, time and information redundancy which can help systems continue operating despite failures.
Presentation was delivered in a fault tolerance class which talk about the achieving fault tolerance in databases by making use of the replication.Different commercial databases were studied and looked into the approaches they took for replication.Then based on the study an architecture was suggested for military database design using an asynchronous approach and making use of the cluster patterns.
This document summarizes a presentation given by Mikael Lindvall and Dharma Ganesan of the Fraunhofer Center for Experimental Software Engineering Maryland on software architecture, reverse engineering, and analyzing legacy systems. The Fraunhofer Center develops techniques for analyzing the structure and behavior of legacy software using methods and tools. They have analyzed several large legacy systems, including NASA's Space Network and Core Flight Software. The presentation describes their model of software architecture and reverse engineering, which involves creating views of the runtime and development architecture from source code. It also gives an example of how they analyzed the Common Ground System, a ground system for NASA missions, by visualizing its actual architecture based on source code.
Modern business drivers are continually pushing to reduce the time it takes to get a product or service to market, reduce the risk and cost associated with that, and to improve quality.
In laboratories, delivering an analytical result that’s ‘right first time’ (RFT) is the answer. There is no reprocessing data or re-running injections and no out of specification (OOS) results or reporting/calculation errors.
Using chromatography data system tools for RFT analysis automatically gives high quality of results and confidence in results, lower cost of analysis, improved lab efficiency, and faster release to market and return on investment (ROI).
In this presentation which was delivered to testers in Manchester, I help would-be performance testers to get started in performance testing. Drawing on my experiences as a performance tester and test manager, I explain the principles of performance testing and highlight some of the pitfalls.
What activates a bug? A refinement of the Laprie terminology model.Peter Tröger
The document proposes refinements to the Laprie terminology model for describing software bugs. It introduces concepts of a fault model describing faulty code, a fault condition model describing enabling system states, and an error model describing states where faults are activated and may lead to failures. A failure automaton is presented with states for disabled, dormant, and active faults, as well as detected errors and outages. Events are defined for when fault conditions are fulfilled or no longer fulfilled, faulty code is executed, and failures occur. The refinement aims to separately consider investigated software layers and their environment in order to better describe what activates bugs.
This document discusses fault-tolerant design techniques for real-time systems. It covers fault masking, reconfiguration, redundancy in hardware, software, and information. Specific techniques discussed include majority voting, error correcting memories, reconfiguration through fault detection, location, containment, and recovery. Hardware redundancy approaches like triple modular redundancy are examined, as are software redundancy techniques like N-version programming and recovery blocks.
Fault recovery tactics in software systems include:
- Voting with redundant components to detect and correct faults. Diversity uses different software/hardware to detect algorithm faults.
- Active redundancy keeps redundant components synchronized in real-time, allowing recovery in milliseconds by switching to backups.
- Passive redundancy uses a primary component with backup components that are periodically resynchronized, allowing recovery in seconds.
- Using spare components requires reconfiguring software and state on the spare, increasing recovery time to minutes.
- Other tactics for recovering failed components include running them in shadow mode, resynchronizing their state, and rolling back to checkpoints.
The document discusses software fault tolerance techniques. It begins by explaining why fault tolerant software is needed, particularly for safety critical systems. It then covers single version techniques like checkpointing and process pairs. Next it discusses multi-version techniques using multiple variants of software. It also covers software fault injection testing. Finally it provides examples of fault tolerant systems used in aircraft like the Airbus and Boeing.
Formal verification is the process of proving or disproving properties of a system using precise mathematical methods. It provides guarantees that no simulations will violate specified properties. Formal verification can be applied at the block and system-on-chip levels to eliminate bugs early. However, current formal verification tools have limitations including capacity issues, generating coverage metrics from assertions, and handling large designs and multiple modes of operation. Improving formal verification requires efficient strategies and advancing tool capabilities.
Formal verification involves proving the correctness of algorithms or systems with respect to a formal specification using mathematical techniques. It can be done by formally modeling a system and using theorem proving or model checking to verify that the model satisfies given properties. Theorem proving uses logical deduction to prove properties, while model checking automatically checks all possible states of a finite model against temporal logic properties. Both approaches have advantages and limitations, but formal verification can help find bugs and prove correctness of systems.
This document discusses software testing for embedded systems. It covers different types of testing including unit, integration, system, and acceptance testing. It also discusses testing at different stages of the development lifecycle. Key aspects of testing covered include functional testing, non-functional testing, structural testing, regression testing, and maintenance testing. The goal of testing is to find defects and ensure software quality in terms of functionality, reliability, usability, and other factors.
Fault-tolerant computer systems are designed to continue operating properly even when some components fail. They achieve this through techniques like redundancy, where backup components take over if primary components fail. The document discusses the goals of fault tolerance like ensuring no single point of failure. It provides examples of how fault tolerance is implemented in areas like data storage and outlines techniques used to design and evaluate fault-tolerant systems.
Fault tolerance systems use hardware and software redundancy to continue operating satisfactorily despite failures. They employ techniques like triplication and voting where multiple processors compute the same parameter and vote to ignore suspect values. Duplication and comparison has two processors compare outputs and drop off if disagreement. Self-checking pairs can detect their own errors. Fault tolerant software uses multi-version programming with different teams developing versions, recovery blocks that re-execute if checks fail, and exception handlers.
A fault tolerant system is able to continue operating despite failures in hardware or software components. It gracefully degrades performance as more faults occur rather than collapsing suddenly. The goal is to ensure the probability of total system failure remains acceptably small. Redundancy is a key technique, with hardware redundancy using multiple redundant components and voting on outputs to mask faults. Static pairing and N modular redundancy are two hardware redundancy methods.
The document discusses faults, errors, and failures in systems. A fault is a defect, an error is unexpected behavior, and a failure occurs when specifications are not met. Fault tolerance allows a system to continue operating despite errors. Fault tolerant systems are gracefully degradable and aim to ensure small failure probabilities. Faults can be hardware or software issues. Various failure types and objectives of fault tolerance like availability and reliability are also described.
This document discusses real-time systems and provides an overview of key concepts in two sessions. The first session defines real-time systems, distinguishes between hard and soft real-time categories, and covers design approaches like super-loops and multitasking. The second session defines real-time operating systems, discusses common commercial and free RTOSs, and explains concepts like tasks, kernels, schedulers, preemptive vs. non-preemptive scheduling, and inter-task communication methods.
This document discusses techniques for achieving fault tolerance in systems. It defines key terms like fault, error, failure and describes different types of faults like hardware faults and software faults. It also discusses fault detection methods like online and offline detection. The document covers different approaches to provide redundancy for fault tolerance like hardware, software, time and information redundancy which can help systems continue operating despite failures.
Presentation was delivered in a fault tolerance class which talk about the achieving fault tolerance in databases by making use of the replication.Different commercial databases were studied and looked into the approaches they took for replication.Then based on the study an architecture was suggested for military database design using an asynchronous approach and making use of the cluster patterns.
This document summarizes a presentation given by Mikael Lindvall and Dharma Ganesan of the Fraunhofer Center for Experimental Software Engineering Maryland on software architecture, reverse engineering, and analyzing legacy systems. The Fraunhofer Center develops techniques for analyzing the structure and behavior of legacy software using methods and tools. They have analyzed several large legacy systems, including NASA's Space Network and Core Flight Software. The presentation describes their model of software architecture and reverse engineering, which involves creating views of the runtime and development architecture from source code. It also gives an example of how they analyzed the Common Ground System, a ground system for NASA missions, by visualizing its actual architecture based on source code.
Modern business drivers are continually pushing to reduce the time it takes to get a product or service to market, reduce the risk and cost associated with that, and to improve quality.
In laboratories, delivering an analytical result that’s ‘right first time’ (RFT) is the answer. There is no reprocessing data or re-running injections and no out of specification (OOS) results or reporting/calculation errors.
Using chromatography data system tools for RFT analysis automatically gives high quality of results and confidence in results, lower cost of analysis, improved lab efficiency, and faster release to market and return on investment (ROI).
In this presentation which was delivered to testers in Manchester, I help would-be performance testers to get started in performance testing. Drawing on my experiences as a performance tester and test manager, I explain the principles of performance testing and highlight some of the pitfalls.
The document discusses software testing and analysis. It describes the goals of verification and validation as establishing confidence that software is fit for purpose without being completely defect-free. Both verification and validation are whole-life cycle processes involving static and dynamic techniques to discover defects and assess usability. The document outlines different testing and inspection methods like unit testing, integration testing, walkthroughs, and inspections and their roles in the verification and validation process.
The document discusses risk based testing and random testing approaches. It outlines the challenges of time and resource constraints when testing software. Risk based testing uses risk analysis and metrics to focus testing on high risk areas in order to save time and money while maintaining quality. Metrics are developed to manage and organize large test projects. Random testing involves automatically generating random inputs and scenarios to stress test software in ways not covered by nominal testing. It can be used with differential and fault injection testing against a reference implementation to automatically check test results.
The document discusses performance tuning for Grails applications. It outlines that performance aspects include latency, throughput, and quality of operations. Performance tuning optimizes costs and ensures systems meet requirements under high load. Amdahl's law states that parallelization cannot speed up non-parallelizable tasks. The document recommends measuring and profiling, making single changes in iterations, and setting up feedback cycles for development and production environments. Common pitfalls in profiling Grails applications are also discussed.
Software engineering quality assurance and testingBipul Roy Bpl
The presentation discusses software quality assurance and testing. It covers topics such as the importance of software quality, types of software quality (functional and non-functional), software testing principles and processes. The testing process involves test planning, analysis and design, implementation and execution, evaluating results, and closure activities. The presentation emphasizes that testing is a critical part of the software development process to improve quality and find defects.
Unit 8 discusses software testing concepts including definitions of testing, who performs testing, test characteristics, levels of testing, and testing approaches. Unit testing focuses on individual program units while integration testing combines units. System testing evaluates a complete integrated system. Testing strategies integrate testing into a planned series of steps from requirements to deployment. Verification ensures correct development while validation confirms the product meets user needs.
This document discusses approaches for managing risk in innovation projects through reliability engineering. It describes three methods: theoretical using standards and simulations, pragmatic with accelerated testing, and analytical using probability of failure calculations. The theoretical approach involves scoping subsystems and identifying reliability metrics from norms. Calculations include MTBF and FIT rates. Simulations validate designs through FEA, software, and system modeling. Pragmatic testing uses highly accelerated life testing to discover weaknesses early in design phases. The goal is to improve reliability and reduce costs from late-stage changes.
A system is a collection of elements or components organized for a common purpose. A system's life cycle includes feasibility study, analysis and specification, design, implementation, and maintenance/support phases. During feasibility study, the problem and scope are defined. Analysis and specification gathers requirements. Design transforms requirements into a structure. Implementation codes the design. Maintenance supports the system after installation and implements changes over time.
System testing evaluates a complete integrated system to determine if it meets specified requirements. It tests both functional and non-functional requirements. Functional requirements include business rules, transactions, authentication, and external interfaces. Non-functional requirements include performance, reliability, security, and usability. There are different types of system testing, including black box testing which tests functionality without knowledge of internal structure, white box testing which tests internal structures, and gray box testing which is a combination. Input, installation, graphical user interface, and regression testing are examples of different types of system testing.
QA and testing are both important for software quality but have different goals. QA is a preventative, process-oriented activity aimed at preventing bugs, while testing is product-oriented and aimed at finding bugs. Key differences between QA and testing are outlined. The document also defines terms like quality control, verification and validation. It describes various testing types like unit, integration, system and acceptance testing as well as techniques like black-box vs white-box testing and manual vs automated testing. Concepts covered include test plans, cases, scripts, suites, logs, beds and deliverables. The importance of a successful test plan is emphasized.
Non-functional requirements describe how a system will operate rather than what it will do. They include qualities like usability, reliability, performance, and supportability. Usability measures how easy a system is to use, learn, and adapt to user needs. Reliability refers to the likelihood of failures and is measured by metrics like mean time between failures. Performance requirements specify the system's efficiency and response times. Supportability involves how easily a system can be maintained, internationalized, and adapted to changes.
This lecture is about the detail definition of software quality and quality assurance. Provide details about software tesing and its types. Clear the basic concepts of software quality and software testing.
This document discusses context-driven test automation and describes four common contexts for automation: individual developer, development team, project, and product line. It analyzes two case studies - the ITE and xBVT test automation frameworks - and how they address common test automation tasks like distribution, setup/teardown, execution, verification and reporting differently depending on their context. The key lesson is that the approach that works best depends on who writes and uses the tests rather than a one-size-fits-all framework. Defining the context upfront helps determine how automation tasks are implemented.
This document discusses various software testing techniques. It begins by explaining the goals of verification and validation as establishing confidence that software is fit for its intended use. It then covers different testing phases from component to integration testing. The document discusses both static and dynamic verification methods like inspections, walkthroughs, and testing. It details test case development techniques like equivalence partitioning and boundary value analysis. Finally, it covers white-box and structural testing methods that derive test cases from examining a program's internal structure.
Process and Regulated Processes Software Validation ElementsArta Doci
Medical device manufacturers operate in a competitive marketplace with increasing end-user demands for features and usability and in a highly regulated environment.
Regulatory bodies look for evidence that medical devices are developed under a structured, quality-oriented development process. By following software validation and verification best practices, one can not only increase the likelihood that they will meet their compliance goals, they can also enhance developer productivity.
Data Integrity II - Chromatography data system (CDS) in PharmaSathish Vemula
- Introduction
- Functions of CDS
- Validation of CDS
- Regulatory requirements
- Procedures required
- Areas for ensuring CDS Data Integrity
- Previous observations
- FDA Warning Letters – 2013
- FDA Warning Letters – 2014
- FDA 483’s related to CDS
- EU – Non compliance Reports
- WHO - Notice of Concern
- How to avoid observations ?
- Conclusion
Quality attributes in software architectureGang Tao
This document discusses various quality attributes in software architecture including responsiveness, scalability, usability, security, accessibility, serviceability, extensibility, distributability, maintainability, portability, reliability, testability, and compatibility. For each attribute, it provides definitions and considerations for how to achieve that attribute in architecture and design. It also discusses relationships between attributes and references quality models for evaluating software.
Testing- Fundamentals of Testing-Mazenet solutionMazenetsolution
For Youtube Videos: bit.do/sevents
Why testing is necessary,Fundamental test process, Psychology of testing, Re-testing and regression testing,
Expected results,Prioritisation of tests
Software test automation involves developing automated test scripts to test software. There are several benefits to test automation including saving time, freeing up test engineers from repetitive tasks, improving reliability of tests, and enabling certain types of testing. Effective test automation requires identifying what to automate based on factors like test type, prone to change areas, and standards. It also requires skills in test case design, frameworks, programming languages, and reporting. Proper design and requirements are needed for the test automation framework and tools. The test automation process should follow the same development lifecycle model as the product.
Similar to Dependable Systems -Dependability Means (3/16) (20)
Dr. Peter Tröger discusses cloud standards and virtualization. He outlines three basic cloud service models and describes challenges with cloud dependability from the customer and provider perspectives. The document also reviews several standards organizations and specifications relevant to cloud computing, including OVF, OCCI, CDMI, and the Cloud Security Alliance. It emphasizes that while infrastructure standards are maturing, more work remains regarding platforms, software, data models, and billing standards.
Distributed Resource Management Application API (DRMAA) Version 2Peter Tröger
The document describes the Distributed Resource Management Application API (DRMAA) version 2. It provides an overview of DRMAA and its goals of providing a standardized API for distributed resource management systems. It discusses the key components involved in DRMAA including distributed resource management systems, DRMAA implementations/libraries, submission hosts, and execution hosts. It also summarizes the success of DRMAA version 1 and outlines the status and design approach of the new DRMAA version 2 specification.
Design of Software for Embedded SystemsPeter Tröger
This document provides an overview of the Design of Software for Embedded Systems (SWES) course. It discusses the course organization, project requirements, and introduces some basic concepts and terminology related to embedded systems and real-time software. Specifically, it describes the challenges in embedded system design, different types of hardware platforms, characteristics of embedded software, issues related to timeliness and real-time scheduling, and how real-time operating systems address these issues. The document aims to equip students with foundational knowledge on embedded systems and real-time systems engineering.
Human users should not be forced to edit XML documents. Sometimes, they may want to read it.
The presentation persists some arguments I stated about this topic again and again in the past. Discussions and opinions are more than welcome.
This document provides a summary of the history of operating systems from the earliest mechanical computers in the 1800s to modern desktop and server operating systems. It discusses the first programmable computers like the Analytical Engine and Z3 and the development of stored program architectures. It then covers the evolution of batch processing systems and time-sharing to allow for interactive use. Key developments discussed include the IBM 1401, CTSS, Multics, Unix, and early versions of Windows. The document also provides an overview of basic hardware concepts like SMP, multi-core processors, and parallelism that operating systems must account for.
Operating Systems 1 (8/12) - ConcurrencyPeter Tröger
This document provides an introduction to concurrency and parallel programming concepts using POSIX threads. It defines key concurrency terms like race conditions, deadlocks, livelocks and starvation. It discusses how to protect critical sections and shared resources using semaphores and mutexes. Examples like the dining philosophers problem illustrate how deadlocks can occur. The document also outlines POSIX thread functions for thread management, synchronization with mutexes and condition variables, and reading/writing locks and barriers.
Operating Systems 1 (9/12) - Memory Management ConceptsPeter Tröger
The document discusses memory management concepts in operating systems including:
- Memory is a critical resource that must be managed by the operating system to allow multiple processes to efficiently share the physical memory.
- The operating system implements virtual memory which maps process logical addresses to physical addresses to isolate processes.
- A memory management unit (MMU) hardware performs this address translation transparently.
- Memory is organized in a hierarchy from fast expensive cache/RAM to slower cheaper disk storage.
- The operating system uses paging, swapping and memory partitioning to manage this hierarchy and allocate memory to processes.
The document discusses processes and threads in operating systems. It describes how processes contain multiple threads that can run concurrently on multicore systems. Each thread has its own execution state and context stored in a thread control block. When a thread is not actively running, its context is saved so it can resume execution later. The document provides examples of how threads are implemented in Windows and Linux operating systems.
The document provides a history of early computers and operating systems, beginning with Charles Babbage's analytical engine in the 1820s. It discusses the earliest digital computers in the 1940s-1950s and their use of serial processing. Batch processing was introduced with the IBM 1401 in 1959 to improve resource utilization. Multi-programming was developed in the 1960s to further increase CPU usage by running multiple jobs simultaneously. Time-sharing systems in the 1960s allowed for interactive use by multiple users through fast context switching. Modern operating systems evolved from these early batch processing and time-sharing systems.
Operating Systems 1 (3/12) - ArchitecturesPeter Tröger
The document discusses operating system architectures and provides examples of different architectures. It begins by explaining that operating systems provide a layered architecture that hides the complexity of underlying hardware and manages system resources. It then provides examples of monolithic, layered, and microkernel architectures. Specifically, it summarizes Linux as having a layered kernel and user mode, VMS and Windows as having layered designs with executive and kernel layers, and microkernel designs placing most functionality in user-mode servers.
Operating Systems 1 (6/12) - ProcessesPeter Tröger
The document discusses operating system concepts related to processes. It covers:
1) The core operating system task of managing multiple running processes through techniques like multi-processing and multi-tasking.
2) A process is the unit of execution and is represented by a process control block containing its state and resource usage information.
3) Processes go through various states in their lifecycle including running, ready, blocked, and terminated as they are scheduled by the operating system dispatcher.
Operating Systems 1 (5/12) - Architectures (Unix)Peter Tröger
Modern operating systems like Unix, Linux, and Mac OS X share common goals and design principles. They all aim to abstract away the underlying hardware, manage system resources efficiently, and provide security and flexibility through layering. Key concepts they employ include processes, virtual memory, user/kernel modes enabled by hardware rings, system APIs for applications to access kernel functionality, and pluggable drivers for hardware devices. Their architectures have evolved from early Unix systems through influential versions like System V and BSD to the major modern variants in use today.
Operating Systems 1 (4/12) - Architectures (Windows)Peter Tröger
The Windows operating system was developed to meet requirements for a 32-bit, preemptive, virtual memory OS that could run on multiple hardware architectures and scales well on multiprocessing systems. It was designed to be extensible, portable, dependable, compatible with older systems, and high performing. The Windows kernel implements low-level processor-dependent functions and services like threading, interrupts, and synchronization. Device drivers translate I/O calls to hardware-specific requests using kernel and HAL functions. The HAL abstracts platform-specific details and presents a uniform I/O interface.
हिंदी वर्णमाला पीपीटी, hindi alphabet PPT presentation, hindi varnamala PPT, Hindi Varnamala pdf, हिंदी स्वर, हिंदी व्यंजन, sikhiye hindi varnmala, dr. mulla adam ali, hindi language and literature, hindi alphabet with drawing, hindi alphabet pdf, hindi varnamala for childrens, hindi language, hindi varnamala practice for kids, https://www.drmullaadamali.com
A Strategic Approach: GenAI in EducationPeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
Main Java[All of the Base Concepts}.docxadhitya5119
This is part 1 of my Java Learning Journey. This Contains Custom methods, classes, constructors, packages, multithreading , try- catch block, finally block and more.
Introduction to AI for Nonprofits with Tapp NetworkTechSoup
Dive into the world of AI! Experts Jon Hill and Tareq Monaur will guide you through AI's role in enhancing nonprofit websites and basic marketing strategies, making it easy to understand and apply.
Physiology and chemistry of skin and pigmentation, hairs, scalp, lips and nail, Cleansing cream, Lotions, Face powders, Face packs, Lipsticks, Bath products, soaps and baby product,
Preparation and standardization of the following : Tonic, Bleaches, Dentifrices and Mouth washes & Tooth Pastes, Cosmetics for Nails.
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...PECB
Denis is a dynamic and results-driven Chief Information Officer (CIO) with a distinguished career spanning information systems analysis and technical project management. With a proven track record of spearheading the design and delivery of cutting-edge Information Management solutions, he has consistently elevated business operations, streamlined reporting functions, and maximized process efficiency.
Certified as an ISO/IEC 27001: Information Security Management Systems (ISMS) Lead Implementer, Data Protection Officer, and Cyber Risks Analyst, Denis brings a heightened focus on data security, privacy, and cyber resilience to every endeavor.
His expertise extends across a diverse spectrum of reporting, database, and web development applications, underpinned by an exceptional grasp of data storage and virtualization technologies. His proficiency in application testing, database administration, and data cleansing ensures seamless execution of complex projects.
What sets Denis apart is his comprehensive understanding of Business and Systems Analysis technologies, honed through involvement in all phases of the Software Development Lifecycle (SDLC). From meticulous requirements gathering to precise analysis, innovative design, rigorous development, thorough testing, and successful implementation, he has consistently delivered exceptional results.
Throughout his career, he has taken on multifaceted roles, from leading technical project management teams to owning solutions that drive operational excellence. His conscientious and proactive approach is unwavering, whether he is working independently or collaboratively within a team. His ability to connect with colleagues on a personal level underscores his commitment to fostering a harmonious and productive workplace environment.
Date: May 29, 2024
Tags: Information Security, ISO/IEC 27001, ISO/IEC 42001, Artificial Intelligence, GDPR
-------------------------------------------------------------------------------
Find out more about ISO training and certification services
Training: ISO/IEC 27001 Information Security Management System - EN | PECB
ISO/IEC 42001 Artificial Intelligence Management System - EN | PECB
General Data Protection Regulation (GDPR) - Training Courses - EN | PECB
Webinars: https://pecb.com/webinars
Article: https://pecb.com/article
-------------------------------------------------------------------------------
For more information about PECB:
Website: https://pecb.com/
LinkedIn: https://www.linkedin.com/company/pecb/
Facebook: https://www.facebook.com/PECBInternational/
Slideshare: http://www.slideshare.net/PECBCERTIFICATION
Exploiting Artificial Intelligence for Empowering Researchers and Faculty, In...Dr. Vinod Kumar Kanvaria
Exploiting Artificial Intelligence for Empowering Researchers and Faculty,
International FDP on Fundamentals of Research in Social Sciences
at Integral University, Lucknow, 06.06.2024
By Dr. Vinod Kumar Kanvaria
A review of the growth of the Israel Genealogy Research Association Database Collection for the last 12 months. Our collection is now passed the 3 million mark and still growing. See which archives have contributed the most. See the different types of records we have, and which years have had records added. You can also see what we have for the future.
How to Fix the Import Error in the Odoo 17Celine George
An import error occurs when a program fails to import a module or library, disrupting its execution. In languages like Python, this issue arises when the specified module cannot be found or accessed, hindering the program's functionality. Resolving import errors is crucial for maintaining smooth software operation and uninterrupted development processes.
Thinking of getting a dog? Be aware that breeds like Pit Bulls, Rottweilers, and German Shepherds can be loyal and dangerous. Proper training and socialization are crucial to preventing aggressive behaviors. Ensure safety by understanding their needs and always supervising interactions. Stay safe, and enjoy your furry friends!
1. Dependable Systems
!
Dependability Means
Dr. Peter Tröger
!
Sources:
!
J.C. Laprie. Dependability: Basic Concepts and Terminology
Eusgeld, Irene et al.: Dependability Metrics. 4909. Springer Publishing, 2008
Echtle, Klaus: Fehlertoleranzverfahren. Heidelberg, Germany : Springer Verlag, 1990.
Pfister, Gregory F.: High Availability. In: In Search of Clusters. , S. 379-452
!
2. Dependable Systems Course PT 2014
Dependability
• Umbrella term for operational requirements on a system
• IFIP WG 10.4: "[..] the trustworthiness of a computing system which allows reliance
to be justifiably placed on the service it delivers [..]"
• IEC IEV: "dependability (is) the collective term used to describe the availability
performance and its influencing factors : reliability performance, maintainability
performance and maintenance support performance"
• Laprie: „ Trustworthiness of a computer system such that
reliance can be placed on the service it delivers to the user “
• Adds a third dimension to system quality
• General question: How to deal with unexpected events ?
• In German: ,Verlässlichkeit‘ vs. ,Zuverlässigkeit‘
2
4. Dependable Systems Course PT 2014
Means for Dependability
• Fault prevention - Prevent fault occurrence or introduction
• Fault tolerance - Provide service matching the specification under faults
• Fault removal - How to reduce the presence of faults
• Fault forecasting- Estimate the present number, future incidence, and the
consequences of faults
• Combined utilization
4
5. Dependable Systems Course PT 2014
Dependability Means (Laprie)
• Offline / online techniques
• Fault intolerance techniques
• Fault prevention - Prevent fault occurrence or introduction
• Fault removal - Reduce the presence of faults
• 100% fault-free servicing for the whole life time is not possible
• Fault tolerance techniques
• Fault forecasting - Estimate the present number, future incidence, and the
consequences of faults
• Fault tolerance - Provide service complying with specification in spite of faults
• Problems with coverage and validation of the validator
5
7. Dependable Systems Course PT 2014
Fault Prevention
• Specific approaches for avoiding faults
• Specialized specification formalisms and techniques
• Specialized development / manufacturing process to prevent design faults
• Shielding
• Only use ultra-reliable components
• Choice of programming language
• General engineering approaches
• Software engineering procedures
• Quality management regulations and enforcement
• Training and organization of maintenance departments
7
8. Dependable Systems Course PT 2014
Fault Removal
• Make faults disappear before fault tolerance becomes relevant
• Step 1: Verification
• Check if the system adheres to verification conditions; if not, take next steps
• Static verification: Static analysis, data flow analysis, compiler checks
• Dynamic verification: Symbolic execution or verification testing
• Step 2: Diagnosis
• Find the faults that influenced the verification conditions
• Step 3: Correction
• Fix the problem, repeat the steps (regression)
• Fault removal during operation: Corrective maintenance (curative / preventive)
8
9. Dependable Systems Course PT 2014
Testing
• Selecting test inputs is driven from different view points
• Testing purpose: conformance testing, fault-finding testing
• System model: functional testing (with functional model) or structural testing
• Fault model: enables fault-based testing
• Deterministic testing vs. random testing
• Structural testing of hardware is fault-finding, fault-based, structural testing
• Structural testing of software is fault-finding, non-fault-based, structural testing
• Golden unit: Reference system for comparison of output for a given input
(e.g. reference implementation)
9
10. Dependable Systems Course PT 2014
Fault Tolerance
• Fault tolerance is the ability of a system to operate correctly in presence of faults.
or
• A system S is called k-fault-tolerant with respect to a set of
algorithms {A1, A2, ... , Ap} and a set of faults {F1, F2, ... , Fp}
if for every k-fault F in S, Ai is executable by a subsystem of system S with k faults.
(Hayes, 9/76)
or
• Fault tolerance is the use of redundancy (time or space) to achieve the desired level
of system dependability - costs !
• Accepts that an implemented system will not be fault-free
• Implements automatic recovery from errors
• Is a recursive concept (voter replication, self-checking checkers, stable memory)
10
11. Dependable Systems Course PT 2014
Fault Tolerance
• Typical design methodology in many technical and biological systems
• Spare wheel in cars, redundant organs, ...
• Fault tolerance mechanisms need to be evaluated by dependability attributes
• Minimum, maximum, average reliability and availability
• Easy to formulate and understand, hard to prove - failure rate remains unknown
• Quantitative limits based on fault model (which faults in which components)
• Typically ,one-fault-at-a-time‘ assumption
• Different attributes of fault tolerance implementation to be checked
• Functional verification, sensitivity analysis, minimum amount of resource resp.
computational overhead, implementation performance, transparency, portability
11
12. Error Processing
Dependable Systems Course PT 2014
Phases of Fault Tolerance (Hanmer)
12
Latent
Fault
Error
Normal
OperationFault
Activation
Error Recovery
Error Mitigation
Error
Detection
Fault
Treatment
13. Dependable Systems Course PT 2014
Decomposition of Fault Tolerance (Lee & Anderson)
• Error detection
• Presence of fault is deducted by detecting an error in some subsystem
• Implies failure of the according component
• Damage confinement
• Delimit damage caused due to the component failure
• Error processing - recovery / compensation
• System recovers from the effect of an error
• Fault treatment
• Ensure that fault does not cause again failures
13
14. Dependable Systems Course PT 2014
Fault Tolerance - Error Detection
• Replication check
• Output of replicated components is compared / voted
• Independent failures, physical causes -> many replicas possible (e.g. HW)
• Finds also design faults, if replicated components are from different vendors
• Timing checks (‚watchdog timers‘)
• Timing violation often implies that component output is also incorrect
• Typical solution for node failure detection in a distributed system
• Reasonableness checks - Run-time range checks, assertions
• Structural and coding checks, diagnostics checks, algorithmic checks
• Ideal: Self-checking component with clear error confinement areas
14
15. Dependable Systems Course PT 2014
Fault Tolerance - Error Detection
• Replication checks are powerful and expensive, examples:
• Execute identical copies on different hardware (component failures)
• Execute separate and different versions (assumes independent design faults)
• Execute same copies different times (transient faults)
• Replicate only portion of the system
• Works for both hardware and software
• Signaling aspect in the error detection task
• Typical software model are exceptions, a way for implementing forward recovery
• Combination fault detection and fault location
15 (C) IEEE
16. Dependable Systems Course PT 2014
Fault Tolerance - Damage Confinement (Taylor)
• System decomposition
• Every communication link might enable damage spreading
• Introduce mutual suspicion
• Hardware-based separation of software components
• OS-based separation (processes, runtime monitors, special shells)
• Law-governed architecture
• Externalize contrains on interaction by runtime rules
• Strongly-typed language
• Language guarantees the absence of unintended control flows
16
17. Dependable Systems Course PT 2014
Fault Tolerance - Error Processing Through Recovery
• Forward error recovery
• Error is masked to reach again a consistent state (fault compensation)
• Corrective actions need detailled knowledge (damage assessment)
• New state is typically computed in another way
• Examples with compensation: Error correcting codes, non-journaling file
system check, advanced exception handlers, voters
• Backward error recovery
• Roll back to previous consistent state (recovery point / checkpoint)
• Very suitable for transient faults
• Computation can be re-done with same components (retry),
with alternate components (reconfigure), or can be ignored (skip frame)
17
18. Dependable Systems Course PT 2014
Forward & Backward Recovery - Example
• Transaction processing systems support ACID through journaling and backups
• Journal: Audit trail of transactions and database changes
• Forward recovery: Restore a database backup and apply the transaction journal
• Journal provides the intended transaction operation (write-ahead logging) and
the ,after-image‘ for completed transactions
• Replay of all conducted and intended transactions from safe point in history
• Backward recovery (,backout‘): Apply journal ,backwards‘ on current database
• Demands ,before-image‘ before each database modification
• Involves logic of reprocessing aborted transactions, which is time-consuming
• Typically both applied - forward recovery for reaching a stable database status,
and backward recovery of modifications from unfinished transactions
18
19. Dependable Systems Course PT 2014
Fault Tolerance - Fault Treatment
• Fault diagnosis - determine error cause‘s location and nature
• Fault passivation - (remove faulty component &) reconfigure system
• Error processing might already remove the fault - ,soft fault‘
• Typical example are temporary faults
• Fault tolerance manager
• Careful diagnosis with hardware support
• Damage assessment by disabling faulty components automatically
• Example: IBM mainframe architecture
• Software rejuvenation
• Gracefully terminating an application and immediately restarting it at a
clean internal state
19
20. Dependable Systems Course PT 2014
Fault Tolerant Mindset (Hanmer)
• What can go wrong in any given situation ?
• Mindset to be applied in all development stages
• „Every problem in computer science boils down to tradeoffs“ [Henschen]
• Fault prevention vs. fault tolerance vs. failure severity
• KISS principles, leave out „bells and whistles“
• Incremental additions of reliability - long-term products
• Defensive Programming
• Simple error handling; fix root cause, not symptoms; make data auditble;
make code maintainable;
20
21. Dependable Systems Course PT 2014
„Fail-Fast“
• A common concept from system engineering, company management, ...
• „Report failure and stop immediately without further action“
• Discussed by Jim Gray in 1985 as part of his famous article
„Why do computers stop and what can be done about it ?“
• Useful when benefit from recovery is not good enough for its costs,
or if error propagation is highly probable
• Single units of a redundant set
• Deeply interwired IT system components
• Components under heavy request load
• And ... crappy start-up companies
21
22. Dependable Systems Course PT 2014
Fault Tolerant Design Methodology (Hanmer)
• Assess things that can go wrong with the system (e.g. fault trees).
• Find potential risks and according system failures.
• Define strategies to mitigate the identified risks.
• Failure avoidance options, prevent faults from activation
• Create a mental model of the system design with redundancy.
• Design error detection and error processing capabilities.
• Design in the failure mitigation capabilities.
• Design human-computer interactions and modes of management.
22
23. Dependable Systems Course PT 2014
Dependable Design Strategies (Malek)
• Decompose the system
• Identify fault classes, fault latency and fault impact for the components
• Identify “weak spots” and assess potential damage
• Integrate partial recovery / reintegration / restart
• Determine qualitative and quantitative specs for fault tolerance and evaluate your
design in specific environment
• Develop / utilize fault and error detection techniques and algorithms
• Develop / utilize fault isolation techniques and algorithms
• Refine fault tolerance, iterate for improvement
• Re-use proven components, but be aware of integration issues
23