6,349 research outputs found

    DeSyRe: on-Demand System Reliability

    No full text
    The DeSyRe project builds on-demand adaptive and reliable Systems-on-Chips (SoCs). As fabrication technology scales down, chips are becoming less reliable, thereby incurring increased power and performance costs for fault tolerance. To make matters worse, power density is becoming a significant limiting factor in SoC design, in general. In the face of such changes in the technological landscape, current solutions for fault tolerance are expected to introduce excessive overheads in future systems. Moreover, attempting to design and manufacture a totally defect and fault-free system, would impact heavily, even prohibitively, the design, manufacturing, and testing costs, as well as the system performance and power consumption. In this context, DeSyRe delivers a new generation of systems that are reliable by design at well-balanced power, performance, and design costs. In our attempt to reduce the overheads of fault-tolerance, only a small fraction of the chip is built to be fault-free. This fault-free part is then employed to manage the remaining fault-prone resources of the SoC. The DeSyRe framework is applied to two medical systems with high safety requirements (measured using the IEC 61508 functional safety standard) and tight power and performance constraints

    High Performance Spacecraft Computing (HPSC) Middleware Update

    Get PDF
    High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes, an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an HPSC project update, an overview of the latest HPSC System Software release, an overview of HPSC Middleware Release 2, and a preview of the third HPSC Middleware release. The presentation will begin with a project update that will provide a look at the high-level changes since the project was introduced at the Flight Software Workshop last year. Next, the presentation will provide an overview of the current suite of HPSC System Software which includes the vendor provided bootloaders, operating systems, emulator, and development tools. Next, the HPSC Middleware progress will be presented, which includes an overview of the features and capabilities of HPSC Middleware Release 2, followed by a look at the reference flight software applications which utilize the Middleware. Finally, the presentation will give a preview of the HPSC Middleware Release 3

    ๋ณ‘๋ ฌ ๋ฐ ๋ถ„์‚ฐ ์ž„๋ฒ ๋””๋“œ ์‹œ์Šคํ…œ์„ ์œ„ํ•œ ๋ชจ๋ธ ๊ธฐ๋ฐ˜ ์ฝ”๋“œ ์ƒ์„ฑ ํ”„๋ ˆ์ž„์›Œํฌ

    Get PDF
    ํ•™์œ„๋…ผ๋ฌธ(๋ฐ•์‚ฌ)--์„œ์šธ๋Œ€ํ•™๊ต ๋Œ€ํ•™์› :๊ณต๊ณผ๋Œ€ํ•™ ์ปดํ“จํ„ฐ๊ณตํ•™๋ถ€,2020. 2. ํ•˜์ˆœํšŒ.์†Œํ”„ํŠธ์›จ์–ด ์„ค๊ณ„ ์ƒ์‚ฐ์„ฑ ๋ฐ ์œ ์ง€๋ณด์ˆ˜์„ฑ์„ ํ–ฅ์ƒ์‹œํ‚ค๊ธฐ ์œ„ํ•ด ๋‹ค์–‘ํ•œ ์†Œํ”„ํŠธ์›จ์–ด ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์ด ์ œ์•ˆ๋˜์—ˆ์ง€๋งŒ, ๋Œ€๋ถ€๋ถ„์˜ ์—ฐ๊ตฌ๋Š” ์‘์šฉ ์†Œํ”„ํŠธ์›จ์–ด๋ฅผ ํ•˜๋‚˜์˜ ํ”„๋กœ์„ธ์„œ์—์„œ ๋™์ž‘์‹œํ‚ค๋Š” ๋ฐ์— ์ดˆ์ ์„ ๋งž์ถ”๊ณ  ์žˆ๋‹ค. ๋˜ํ•œ, ์ž„๋ฒ ๋””๋“œ ์‹œ์Šคํ…œ์„ ๊ฐœ๋ฐœํ•˜๋Š” ๋ฐ์— ํ•„์š”ํ•œ ์ง€์—ฐ์ด๋‚˜ ์ž์› ์š”๊ตฌ ์‚ฌํ•ญ์— ๋Œ€ํ•œ ๋น„๊ธฐ๋Šฅ์  ์š”๊ตฌ ์‚ฌํ•ญ์„ ๊ณ ๋ คํ•˜์ง€ ์•Š๊ณ  ์žˆ๊ธฐ ๋•Œ๋ฌธ์— ์ผ๋ฐ˜์ ์ธ ์†Œํ”„ํŠธ์›จ์–ด ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์„ ์ž„๋ฒ ๋””๋“œ ์†Œํ”„ํŠธ์›จ์–ด๋ฅผ ๊ฐœ๋ฐœํ•˜๋Š” ๋ฐ์— ์ ์šฉํ•˜๋Š” ๊ฒƒ์€ ์ ํ•ฉํ•˜์ง€ ์•Š๋‹ค. ์ด ๋…ผ๋ฌธ์—์„œ๋Š” ๋ณ‘๋ ฌ ๋ฐ ๋ถ„์‚ฐ ์ž„๋ฒ ๋””๋“œ ์‹œ์Šคํ…œ์„ ๋Œ€์ƒ์œผ๋กœ ํ•˜๋Š” ์†Œํ”„ํŠธ์›จ์–ด๋ฅผ ๋ชจ๋ธ๋กœ ํ‘œํ˜„ํ•˜๊ณ , ์ด๋ฅผ ์†Œํ”„ํŠธ์›จ์–ด ๋ถ„์„์ด๋‚˜ ๊ฐœ๋ฐœ์— ํ™œ์šฉํ•˜๋Š” ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์„ ์†Œ๊ฐœํ•œ๋‹ค. ์šฐ๋ฆฌ์˜ ๋ชจ๋ธ์—์„œ ์‘์šฉ ์†Œํ”„ํŠธ์›จ์–ด๋Š” ๊ณ„์ธต์ ์œผ๋กœ ํ‘œํ˜„ํ•  ์ˆ˜ ์žˆ๋Š” ์—ฌ๋Ÿฌ ๊ฐœ์˜ ํƒœ์Šคํฌ๋กœ ์ด๋ฃจ์–ด์ ธ ์žˆ์œผ๋ฉฐ, ํ•˜๋“œ์›จ์–ด ํ”Œ๋žซํผ๊ณผ ๋…๋ฆฝ์ ์œผ๋กœ ๋ช…์„ธํ•œ๋‹ค. ํƒœ์Šคํฌ ๊ฐ„์˜ ํ†ต์‹  ๋ฐ ๋™๊ธฐํ™”๋Š” ๋ชจ๋ธ์ด ์ •์˜ํ•œ ๊ทœ์•ฝ์ด ์ •ํ•ด์ ธ ์žˆ๊ณ , ์ด๋Ÿฌํ•œ ๊ทœ์•ฝ์„ ํ†ตํ•ด ์‹ค์ œ ํ”„๋กœ๊ทธ๋žจ์„ ์‹คํ–‰ํ•˜๊ธฐ ์ „์— ์†Œํ”„ํŠธ์›จ์–ด ์—๋Ÿฌ๋ฅผ ์ •์  ๋ถ„์„์„ ํ†ตํ•ด ํ™•์ธํ•  ์ˆ˜ ์žˆ๊ณ , ์ด๋Š” ์‘์šฉ์˜ ๊ฒ€์ฆ ๋ณต์žก๋„๋ฅผ ์ค„์ด๋Š” ๋ฐ์— ๊ธฐ์—ฌํ•œ๋‹ค. ์ง€์ •ํ•œ ํ•˜๋“œ์›จ์–ด ํ”Œ๋žซํผ์—์„œ ๋™์ž‘ํ•˜๋Š” ํ”„๋กœ๊ทธ๋žจ์€ ํƒœ์Šคํฌ๋“ค์„ ํ”„๋กœ์„ธ์„œ์— ๋งคํ•‘ํ•œ ์ดํ›„์— ์ž๋™์ ์œผ๋กœ ํ•ฉ์„ฑํ•  ์ˆ˜ ์žˆ๋‹ค. ์œ„์˜ ๋ชจ๋ธ ๊ธฐ๋ฐ˜ ์†Œํ”„ํŠธ์›จ์–ด ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์—์„œ ์‚ฌ์šฉํ•˜๋Š” ํ”„๋กœ๊ทธ๋žจ ํ•ฉ์„ฑ๊ธฐ๋ฅผ ๋ณธ ๋…ผ๋ฌธ์—์„œ ์ œ์•ˆํ•˜์˜€๋Š”๋ฐ, ๋ช…์„ธํ•œ ํ”Œ๋žซํผ ์š”๊ตฌ ์‚ฌํ•ญ์„ ๋ฐ”ํƒ•์œผ๋กœ ๋ณ‘๋ ฌ ๋ฐ ๋ถ„์‚ฐ ์ž„๋ฒ ๋””๋“œ ์‹œ์Šคํ…œ์„์—์„œ ๋™์ž‘ํ•˜๋Š” ์ฝ”๋“œ๋ฅผ ์ƒ์„ฑํ•œ๋‹ค. ์—ฌ๋Ÿฌ ๊ฐœ์˜ ์ •ํ˜•์  ๋ชจ๋ธ๋“ค์„ ๊ณ„์ธต์ ์œผ๋กœ ํ‘œํ˜„ํ•˜์—ฌ ์‘์šฉ์˜ ๋™์  ํ–‰ํƒœ๋ฅผ ๋‚˜ํƒ€๊ณ , ํ•ฉ์„ฑ๊ธฐ๋Š” ์—ฌ๋Ÿฌ ๋ชจ๋ธ๋กœ ๊ตฌ์„ฑ๋œ ๊ณ„์ธต์ ์ธ ๋ชจ๋ธ๋กœ๋ถ€ํ„ฐ ๋ณ‘๋ ฌ์„ฑ์„ ๊ณ ๋ คํ•˜์—ฌ ํƒœ์Šคํฌ๋ฅผ ์‹คํ–‰ํ•  ์ˆ˜ ์žˆ๋‹ค. ๋˜ํ•œ, ํ”„๋กœ๊ทธ๋žจ ํ•ฉ์„ฑ๊ธฐ์—์„œ ๋‹ค์–‘ํ•œ ํ”Œ๋žซํผ์ด๋‚˜ ๋„คํŠธ์›Œํฌ๋ฅผ ์ง€์›ํ•  ์ˆ˜ ์žˆ๋„๋ก ์ฝ”๋“œ๋ฅผ ๊ด€๋ฆฌํ•˜๋Š” ๋ฐฉ๋ฒ•๋„ ๋ณด์—ฌ์ฃผ๊ณ  ์žˆ๋‹ค. ๋ณธ ๋…ผ๋ฌธ์—์„œ ์ œ์‹œํ•˜๋Š” ์†Œํ”„ํŠธ์›จ์–ด ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์€ 6๊ฐœ์˜ ํ•˜๋“œ์›จ์–ด ํ”Œ๋žซํผ๊ณผ 3 ์ข…๋ฅ˜์˜ ๋„คํŠธ์›Œํฌ๋กœ ๊ตฌ์„ฑ๋˜์–ด ์žˆ๋Š” ์‹ค์ œ ๊ฐ์‹œ ์†Œํ”„ํŠธ์›จ์–ด ์‹œ์Šคํ…œ ์‘์šฉ ์˜ˆ์ œ์™€ ์ด์ข… ๋ฉ€ํ‹ฐ ํ”„๋กœ์„ธ์„œ๋ฅผ ํ™œ์šฉํ•˜๋Š” ์›๊ฒฉ ๋”ฅ ๋Ÿฌ๋‹ ์˜ˆ์ œ๋ฅผ ์ˆ˜ํ–‰ํ•˜์—ฌ ๊ฐœ๋ฐœ ๋ฐฉ๋ฒ•๋ก ์˜ ์ ์šฉ ๊ฐ€๋Šฅ์„ฑ์„ ์‹œํ—˜ํ•˜์˜€๋‹ค. ๋˜ํ•œ, ํ”„๋กœ๊ทธ๋žจ ํ•ฉ์„ฑ๊ธฐ๊ฐ€ ์ƒˆ๋กœ์šด ํ”Œ๋žซํผ์ด๋‚˜ ๋„คํŠธ์›Œํฌ๋ฅผ ์ง€์›ํ•˜๊ธฐ ์œ„ํ•ด ํ•„์š”๋กœ ํ•˜๋Š” ๊ฐœ๋ฐœ ๋น„์šฉ๋„ ์‹ค์ œ ์ธก์ • ๋ฐ ์˜ˆ์ธกํ•˜์—ฌ ์ƒ๋Œ€์ ์œผ๋กœ ์ ์€ ๋…ธ๋ ฅ์œผ๋กœ ์ƒˆ๋กœ์šด ํ”Œ๋žซํผ์„ ์ง€์›ํ•  ์ˆ˜ ์žˆ์Œ์„ ํ™•์ธํ•˜์˜€๋‹ค. ๋งŽ์€ ์ž„๋ฒ ๋””๋“œ ์‹œ์Šคํ…œ์—์„œ ์˜ˆ์ƒ์น˜ ๋ชปํ•œ ํ•˜๋“œ์›จ์–ด ์—๋Ÿฌ์— ๋Œ€ํ•ด ๊ฒฐํ•จ์„ ๊ฐ๋‚ดํ•˜๋Š” ๊ฒƒ์„ ํ•„์š”๋กœ ํ•˜๊ธฐ ๋•Œ๋ฌธ์— ๊ฒฐํ•จ ๊ฐ๋‚ด์— ๋Œ€ํ•œ ์ฝ”๋“œ๋ฅผ ์ž๋™์œผ๋กœ ์ƒ์„ฑํ•˜๋Š” ์—ฐ๊ตฌ๋„ ์ง„ํ–‰ํ•˜์˜€๋‹ค. ๋ณธ ๊ธฐ๋ฒ•์—์„œ ๊ฒฐํ•จ ๊ฐ๋‚ด ์„ค์ •์— ๋”ฐ๋ผ ํƒœ์Šคํฌ ๊ทธ๋ž˜ํ”„๋ฅผ ์ˆ˜์ •ํ•˜๋Š” ๋ฐฉ์‹์„ ํ™œ์šฉํ•˜์˜€์œผ๋ฉฐ, ๊ฒฐํ•จ ๊ฐ๋‚ด์˜ ๋น„๊ธฐ๋Šฅ์  ์š”๊ตฌ ์‚ฌํ•ญ์„ ์‘์šฉ ๊ฐœ๋ฐœ์ž๊ฐ€ ์‰ฝ๊ฒŒ ์ ์šฉํ•  ์ˆ˜ ์žˆ๋„๋ก ํ•˜์˜€๋‹ค. ๋˜ํ•œ, ๊ฒฐํ•จ ๊ฐ๋‚ด ์ง€์›ํ•˜๋Š” ๊ฒƒ๊ณผ ๊ด€๋ จํ•˜์—ฌ ์‹ค์ œ ์ˆ˜๋™์œผ๋กœ ๊ตฌํ˜„ํ–ˆ์„ ๊ฒฝ์šฐ์™€ ๋น„๊ตํ•˜์˜€๊ณ , ๊ฒฐํ•จ ์ฃผ์ž… ๋„๊ตฌ๋ฅผ ์ด์šฉํ•˜์—ฌ ๊ฒฐํ•จ ๋ฐœ์ƒ ์‹œ๋‚˜๋ฆฌ์˜ค๋ฅผ ์žฌํ˜„ํ•˜๊ฑฐ๋‚˜, ์ž„์˜๋กœ ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•˜๋Š” ์‹คํ—˜์„ ์ˆ˜ํ–‰ํ•˜์˜€๋‹ค. ๋งˆ์ง€๋ง‰์œผ๋กœ ๊ฒฐํ•จ ๊ฐ๋‚ด๋ฅผ ์‹คํ—˜ํ•  ๋•Œ์— ํ™œ์šฉํ•œ ๊ฒฐํ•จ ์ฃผ์ž… ๋„๊ตฌ๋Š” ๋ณธ ๋…ผ๋ฌธ์˜ ๋˜ ๋‹ค๋ฅธ ๊ธฐ์—ฌ ์‚ฌํ•ญ ์ค‘ ํ•˜๋‚˜๋กœ ๋ฆฌ๋ˆ…์Šค ํ™˜๊ฒฝ์œผ๋กœ ๋Œ€์ƒ์œผ๋กœ ์‘์šฉ ์˜์—ญ ๋ฐ ์ปค๋„ ์˜์—ญ์— ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•˜๋Š” ๋„๊ตฌ๋ฅผ ๊ฐœ๋ฐœํ•˜์˜€๋‹ค. ์‹œ์Šคํ…œ์˜ ๊ฒฌ๊ณ ์„ฑ์„ ๊ฒ€์ฆํ•˜๊ธฐ ์œ„ํ•ด ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•˜์—ฌ ๊ฒฐํ•จ ์‹œ๋‚˜๋ฆฌ์˜ค๋ฅผ ์žฌํ˜„ํ•˜๋Š” ๊ฒƒ์€ ๋„๋ฆฌ ์‚ฌ์šฉ๋˜๋Š” ๋ฐฉ๋ฒ•์œผ๋กœ, ๋ณธ ๋…ผ๋ฌธ์—์„œ ๊ฐœ๋ฐœ๋œ ๊ฒฐํ•จ ์ฃผ์ž… ๋„๊ตฌ๋Š” ์‹œ์Šคํ…œ์ด ๋™์ž‘ํ•˜๋Š” ๋„์ค‘์— ์žฌํ˜„ ๊ฐ€๋Šฅํ•œ ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•  ์ˆ˜ ์žˆ๋Š” ๋„๊ตฌ์ด๋‹ค. ์ปค๋„ ์˜์—ญ์—์„œ์˜ ๊ฒฐํ•จ ์ฃผ์ž…์„ ์œ„ํ•ด ๋‘ ์ข…๋ฅ˜์˜ ๊ฒฐํ•จ ์ฃผ์ž… ๋ฐฉ๋ฒ•์„ ์ œ๊ณตํ•˜๋ฉฐ, ํ•˜๋‚˜๋Š” ์ปค๋„ GNU ๋””๋ฒ„๊ฑฐ๋ฅผ ์ด์šฉํ•œ ๋ฐฉ๋ฒ•์ด๊ณ , ๋‹ค๋ฅธ ํ•˜๋‚˜๋Š” ARM ํ•˜๋“œ์›จ์–ด ๋ธŒ๋ ˆ์ดํฌํฌ์ธํŠธ๋ฅผ ํ™œ์šฉํ•œ ๋ฐฉ๋ฒ•์ด๋‹ค. ์‘์šฉ ์˜์—ญ์—์„œ ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•˜๊ธฐ ์œ„ํ•ด GDB ๊ธฐ๋ฐ˜ ๊ฒฐํ•จ ์ฃผ์ž… ๋ฐฉ๋ฒ•์„ ์ด์šฉํ•˜์—ฌ ๋™์ผ ์‹œ์Šคํ…œ ํ˜น์€ ์›๊ฒฉ ์‹œ์Šคํ…œ์˜ ์‘์šฉ์— ๊ฒฐํ•จ์„ ์ฃผ์ž…ํ•  ์ˆ˜ ์žˆ๋‹ค. ๊ฒฐํ•จ ์ฃผ์ž… ๋„๊ตฌ์— ๋Œ€ํ•œ ์‹คํ—˜์€ ODROID-XU4 ๋ณด๋“œ์—์„œ ์ง„ํ–‰ํ•˜์˜€๋‹ค.While various software development methodologies have been proposed to increase the design productivity and maintainability of software, they usually focus on the development of application software running on a single processing element, without concern about the non-functional requirements of an embedded system such as latency and resource requirements. In this thesis, we present a model-based software development method for parallel and distributed embedded systems. An application is specified as a set of tasks that follow a set of given rules for communication and synchronization in a hierarchical fashion, independently of the hardware platform. Having such rules enables us to perform static analysis to check some software errors at compile time to reduce the verification difficulty. Platform-specific program is synthesized automatically after mapping of tasks onto processing elements is determined. The program synthesizer is also proposed to generate codes which satisfies platform requirements for parallel and distributed embedded systems. As multiple models which can express dynamic behaviors can be depicted hierarchically, the synthesizer supports to manage multiple task graphs with a different hierarchy to run tasks with parallelism. Also, the synthesizer shows methods of managing codes for heterogeneous platforms and generating various communication methods. The viability of the proposed software development method is verified with a real-life surveillance application that runs on six processing elements with three remote communication methods, and remote deep learning example is conducted to use heterogeneous multiprocessing components on distributed systems. Also, supporting a new platform and network requires a small effort by measuring and estimating development costs. Since tolerance to unexpected errors is a required feature of many embedded systems, we also support an automatic fault-tolerant code generation. Fault tolerance can be applied by modifying the task graph based on the selected fault tolerance configurations, so the non-functional requirement of fault tolerance can be easily adopted by an application developer. To compare the effort of supporting fault tolerance, manual implementation of fault tolerance is performed. Also, the fault tolerance method is tested with the fault injection tool to emulate fault scenarios and inject faults randomly. Our fault injection tool, which has used for testing our fault-tolerance method, is another work of this thesis. Emulating fault scenarios by intentionally injecting faults is commonly used to test and verify the robustness of a system. To emulate faults on an embedded system, we present a run-time fault injection framework that can inject a fault on both a kernel and application layer of Linux-based systems. For injecting faults on a kernel layer, two complementary fault injection techniques are used. One is based on Kernel GNU Debugger, and the other is using a hardware breakpoint supported by the ARM architecture. For application-level fault injection, the GDB-based fault injection method is used to inject a fault on a remote application. The viability of the proposed fault injection tool is proved by real-life experiments with an ODROID-XU4 system.Chapter 1 Introduction 1 1.1 Motivation 1 1.2 Contribution 6 1.3 Dissertation Organization 8 Chapter 2 Background 9 2.1 HOPES: Hope of Parallel Embedded Software 9 2.1.1 Software Development Procedure 9 2.1.2 Components of HOPES 12 2.2 Universal Execution Model 13 2.2.1 Task Graph Specification 13 2.2.2 Dataflow specification of an Application 15 2.2.3 Task Code Specification and Generic APIs 21 2.2.4 Meta-data Specification 23 Chapter 3 Program Synthesis for Parallel and Distributed Embedded Systems 24 3.1 Motivational Example 24 3.2 Program Synthesis Overview 26 3.3 Program Synthesis from Hierarchically-mixed Models 30 3.4 Platform Code Synthesis 33 3.5 Communication Code Synthesis 36 3.6 Experiments 40 3.6.1 Development Cost of Supporting New Platforms and Networks 40 3.6.2 Program Synthesis for the Surveillance System Example 44 3.6.3 Remote GPU-accelerated Deep Learning Example 46 3.7 Document Generation 48 3.8 Related Works 49 Chapter 4 Model Transformation for Fault-tolerant Code Synthesis 56 4.1 Fault-tolerant Code Synthesis Techniques 56 4.2 Applying Fault Tolerance Techniques in HOPES 61 4.3 Experiments 62 4.3.1 Development Cost of Applying Fault Tolerance 62 4.3.2 Fault Tolerance Experiments 62 4.4 Random Fault Injection Experiments 65 4.5 Related Works 68 Chapter 5 Fault Injection Framework for Linux-based Embedded Systems 70 5.1 Background 70 5.1.1 Fault Injection Techniques 70 5.1.2 Kernel GNU Debugger 71 5.1.3 ARM Hardware Breakpoint 72 5.2 Fault Injection Framework 74 5.2.1 Overview 74 5.2.2 Architecture 75 5.2.3 Fault Injection Techniques 79 5.2.4 Implementation 83 5.3 Experiments 90 5.3.1 Experiment Setup 90 5.3.2 Performance Comparison of Two Fault Injection Methods 90 5.3.3 Bit-flip Fault Experiments 92 5.3.4 eMMC Controller Fault Experiments 94 Chapter 6 Conclusion 97 Bibliography 99 ์š” ์•ฝ 108Docto

    Towards a methodology for rigorous development of generic requirements patterns

    No full text
    We present work in progress on a methodology for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. We consider the failure detection and management function for engine control systems as an application domain where product line engineering is useful. The methodology produces a generic requirement set in our, UML based, formal notation, UML-B. The formal verification both of the generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools

    Fault-Tolerance by Graceful Degradation for Car Platoons

    Get PDF
    The key advantage of autonomous car platoons are their short inter-vehicle distances that increase traffic flow and reduce fuel consumption. However, this is challenging for operational and functional safety. If a failure occurs, the affected vehicles cannot suddenly stop driving but instead should continue their operation with reduced performance until a safe state can be reached or, in the case of temporal failures, full functionality can be guaranteed again. To achieve this degradation, platoon members have to be able to compensate sensor and communication failures and have to adjust their inter-vehicle distances to ensure safety. In this work, we describe a systematic design of degradation cascades for sensor and communication failures in autonomous car platoons using the example of an autonomous model car. We describe our systematic design method, the resulting degradation modes, and formulate contracts for each degradation level. We model and test our resulting degradation controller in Simulink/Stateflow
    • โ€ฆ
    corecore