DOCSLIB.ORG

The Qualification of Software Development Tools from the DO-178B Certification Perspective

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Qualification of Software Development Tools from the DO-178B Certification Perspective Software Engineering Technology The Qualification of Software Development Tools From the DO-178B Certification Perspective Dr. Andrew J. Kornecki Dr. Janusz Zalewski Embry Riddle Aeronautical University Florida Gulf Coast University Software development tools are in wide use among safety-critical system developers. Examples of such use include aviation, auto- motive, space, nuclear, railroad, medical, and military applications. However, verification of tool output to ensure safety, man- dated in highly regulated industries, requires enormous effort. If a tool is qualified, this effort can be reduced or even eliminat- ed. The Radio Technical Commission for Aeronautics Document Order-178B and related documents provide guidelines by which to qualify these tools. However, current regulations, business models, and industry practice make this goal difficult to accomplish. This article discusses the qualification of development tools and the potential impact of this process on the aviation industry. oftware development tools are com- (SC-167) in 1989 with the objective of context of a specific airborne system.” It is puter programs that help developers updating the DO-178A by focusing on the certification authority that decides on createS other programs. Such tools have five areas: documentation integration and the outcome of the qualification process. been in use since the early days of com- production, system issues, software devel- Moreover, qualification, if claimed, is a puting to improve the efficiency of the opment, software verification, and soft- requirement in getting a system certified. development process by automating mun- ware configuration management and soft- dane translation operations and bringing ware quality assurance. The resulting doc- Types of Software the level of abstraction closer to the appli- ument, DO-178B, provides guidelines for Development Tools cation engineer. Nowadays, development applicants developing software-intensive DO-178B differentiates between verifica- tools are used in a variety of safety-critical airborne systems [1, 2]. It discusses objec- tion tools that cannot introduce errors but may applications, including the aviation, auto- tives that need to be met to show that the fail to detect them and development tools motive, space, nuclear, railroad, medical, software development process provides whose output is part of airborne software and and military industries, and contribute to specified levels of safety assurance. It also thus can introduce errors. There is a signifi- the risks associated with using respective describes the processes and means of cant amount of effort involved to qualify products. Despite these risks to society, compliance. a verification tool, and much more to development tools are rarely qualified in a Systems are categorized by DO-178B qualify a development tool. However, sense comparable to product certification as meeting safety assurance levels A numerous development tools have been in regulated industries. The objective of through E based on their criticality in sup- used successfully in many certified pro- this article is to look at the current state of porting safe aircraft flight. The level A sys- jects without being qualified. To define a the tool qualification process, identify the tem is the most critical: The failure of subject matter more narrowly, we need to issues, and propose recommendations for such a system could result in a catastroph- take a closer look at the entire domain of potential improvement, focusing on the ic failure condition for the aircraft. The software development tools. aviation industry. level E system is the least critical: Such a The landscape of modern software System Certification Versus system has no effect on the operational development tools is very broad, as illus- capability of the aircraft or pilot workload. trated in Figure 1 (see page 20). Following Software Tool Qualification Although the RTCA DO-178B is the lead- the traditional model of the development Certification of airborne equipment is typ- ing source of guidelines for software process from requirements to implemen- ically achieved through the Federal developers engaged in such system con- tation, we can identify the following: Aviation Administration (FAA) authoriza- struction, two other documents have criti- • The requirements category that includes tion of a type certificate (the entire air- cal bearing on the subject. RTCA DO- tools used early in the life cycle to craft), supplemental type certificate (new 248B [3] clarifies some of the misinterpre- identify and specify the software equipment in a specific aircraft), or a tech- tation of the DO-178B. The FAA Order requirements. nical standard order (minimum perfor- 8110.49 compiles a variety of guidelines • The design category that includes tools mance standard for materials, parts, and related to the use of software in airborne allowing developers to create architec- appliances used on civil aircraft). A special systems. Chapter 9 is specifically dedicated tural and detailed design of the soft- committee (SC-145) of the Radio Tech- to tool qualification [4]. ware in a notation of their choice sup- nical Commission for Aeronautics (RTCA) A key component of the updated ver- ported by the tool; often in this cate- convened in 1980 to establish guidelines sion of DO-178B is the concept of tool gory, tools translate the model to for developing airborne systems.The qualification elaborated in Section 12. source code. report “Software Considerations in Air- Qualification is a supplementary process • The implementation category that borne Systems and Equipment Certifica- that the applicant may elect to follow in includes all support required to trans- tion” was published in January 1982 as the the course of certifying an airborne sys- late the computer code and transfer it RTCA Document Order (DO)-178 (and tem. According to the definition given in to the target computer. revised as DO-178A in 1985). DO-178B, tool qualification is defined as, As illustrated in Figure 1, three other Due to rapid advances in technology, “The process necessary to obtain certifica- categories of tools can be identified: those the RTCA established a new committee tion credit for a software tool within the related to analysis, testing, and target. April 2006 www.stsc.hill.af.mil 19 Software Engineering Technology e.g.: a Tool Configuration Management Index, Structural Rhapsody Typically With Design RoseRT Code Generator Tool Development Data, Tool Verification Functionality Tool STOOD Records, Tool Quality Assurance Records, Requirements Artisan Tool Integrated Tool Configuration Management Records, or/and e.g.: Development e.g.: Functional SCADE Environment etc. These requirements are also described Reqtify Design Matlab (IDE) in [4]. Tool qualification data are approved BEACON DOORS Tool e.g.: SpecTRM Sildex Tornado only in the context of the overall software DOME Multi development for the specific system Analysis Implementation where the intention to use the tool is stat- Tool Tool ed in the PSAC. The tool itself does not receive a separate qualification stamp of e.g.: Testing RapidRMA Tool approval. Therefore, using the tool on TimeWiz another system/project requires a separate e.g.: Target qualification, although some qualification CodeTest (with RTOS) TestRT credits may be reused. VectorCast e.g.: Surveys requesting which tools are used Insure++ VxWorks QNX by industry were conducted at two national OSE conferences: the 2002 FAA National Tool Categories Integrity LynxOS Software Conference and the 2004 Embry Riddle Aeronautical University/FAA Soft- Figure 1: Software Tool Categories ware Tool Forum. In addition, two follow- Figure 1:Software Tool Categories up e-mail solicitations were sent to more However, for this article, we will focus pri- producer) is to transform an input artifact than 500 professionals working on air- marily on the tools used in the design into output, thus creating another software borne systems. These surveys and solicita- phase, the central component of the soft- artifact. The current process mandates ver- tions resulted in a relatively small sample of ware development life cycle. They reflect ification after each transformation. If this Can responses that did not provide a base for two divertseool vie inwsertpoints error on real-time, safety- transformation has an impact on the final statistically significant results. The com- NO critical systemsinto a irdevelopment,borne which result airborne product, the producer needs to be ments included industry discouragement NO QUALIFICATION from differentso fdevelopers’tware? backgrounds: qualified, but only if the transformation regarding the rigor of development tool • Control engineers consider a system to output wouldNEC notESS beA verifiedRY and the trans- YES qualification, and a justified perception of be a dynamic model consisting of well- formation leads to elimination, reduction, the extensive cost of qualification. defined blocks of specific functionality or automation of any of the DO-178B Potential solutions to assist in commer- (logic, arithmetic,W dynamic).ill The func- processes. The conditions under which a the tool’s output cial off-the-shelf (COTS) development tional paradigm of the model is the development tool requires qualification are NOT be verified tool qualification included extensive ven- basis for system simulation and analysis presented TinOO FigureL M U2 S[4].T (as specified in NO dor collaboration and using alternate means
Load more

Recommended publications
  • Emerging Technologies Multi/Parallel Processing
    Emerging Technologies Multi/Parallel Processing Mary C. Kulas New Computing Structures Strategic Relations Group December 1987 For Internal Use Only Copyright @ 1987 by Digital Equipment Corporation. Printed in U.S.A. The information contained herein is confidential and proprietary. It is the property of Digital Equipment Corporation and shall not be reproduced or' copied in whole or in part without written permission. This is an unpublished work protected under the Federal copyright laws. The following are trademarks of Digital Equipment Corporation, Maynard, MA 01754. DECpage LN03 This report was produced by Educational Services with DECpage and the LN03 laser printer. Contents Acknowledgments. 1 Abstract. .. 3 Executive Summary. .. 5 I. Analysis . .. 7 A. The Players . .. 9 1. Number and Status . .. 9 2. Funding. .. 10 3. Strategic Alliances. .. 11 4. Sales. .. 13 a. Revenue/Units Installed . .. 13 h. European Sales. .. 14 B. The Product. .. 15 1. CPUs. .. 15 2. Chip . .. 15 3. Bus. .. 15 4. Vector Processing . .. 16 5. Operating System . .. 16 6. Languages. .. 17 7. Third-Party Applications . .. 18 8. Pricing. .. 18 C. ~BM and Other Major Computer Companies. .. 19 D. Why Success? Why Failure? . .. 21 E. Future Directions. .. 25 II. Company/Product Profiles. .. 27 A. Multi/Parallel Processors . .. 29 1. Alliant . .. 31 2. Astronautics. .. 35 3. Concurrent . .. 37 4. Cydrome. .. 41 5. Eastman Kodak. .. 45 6. Elxsi . .. 47 Contents iii 7. Encore ............... 51 8. Flexible . ... 55 9. Floating Point Systems - M64line ................... 59 10. International Parallel ........................... 61 11. Loral .................................... 63 12. Masscomp ................................. 65 13. Meiko .................................... 67 14. Multiflow. ~ ................................ 69 15. Sequent................................... 71 B. Massively Parallel . 75 1. Ametek.................................... 77 2. Bolt Beranek & Newman Advanced Computers ...........
    [Show full text]
  • Publication Title 1-1962
    publication_title print_identifier online_identifier publisher_name date_monograph_published_print 1-1962 - AIEE General Principles Upon Which Temperature 978-1-5044-0149-4 IEEE 1962 Limits Are Based in the rating of Electric Equipment 1-1969 - IEEE General Priniciples for Temperature Limits in the 978-1-5044-0150-0 IEEE 1968 Rating of Electric Equipment 1-1986 - IEEE Standard General Principles for Temperature Limits in the Rating of Electric Equipment and for the 978-0-7381-2985-3 IEEE 1986 Evaluation of Electrical Insulation 1-2000 - IEEE Recommended Practice - General Principles for Temperature Limits in the Rating of Electrical Equipment and 978-0-7381-2717-0 IEEE 2001 for the Evaluation of Electrical Insulation 100-2000 - The Authoritative Dictionary of IEEE Standards 978-0-7381-2601-2 IEEE 2000 Terms, Seventh Edition 1000-1987 - An American National Standard IEEE Standard for 0-7381-4593-9 IEEE 1988 Mechanical Core Specifications for Microcomputers 1000-1987 - IEEE Standard for an 8-Bit Backplane Interface: 978-0-7381-2756-9 IEEE 1988 STEbus 1001-1988 - IEEE Guide for Interfacing Dispersed Storage and 0-7381-4134-8 IEEE 1989 Generation Facilities With Electric Utility Systems 1002-1987 - IEEE Standard Taxonomy for Software Engineering 0-7381-0399-3 IEEE 1987 Standards 1003.0-1995 - Guide to the POSIX(R) Open System 978-0-7381-3138-2 IEEE 1994 Environment (OSE) 1003.1, 2004 Edition - IEEE Standard for Information Technology - Portable Operating System Interface (POSIX(R)) - 978-0-7381-4040-7 IEEE 2004 Base Definitions 1003.1, 2013
    [Show full text]
  • N94-13338 1.1.1 3Rd NASA Symposium on VLSI Design 1991
    N94-13338 1.1.1 3rd NASA Symposium on VLSI Design 1991 Experience with Custom Processors in Space Flight Applications M. E. Fraeman, J. R. Hayes, D. A. Lohr, B. W. Ballard, R. L. Williams, and R. M. Henshaw Johns Hopkins University Applied Physics Laboratory Laurel, Maryland 20723 Abstract- APL has developed a magnetometer instrument for a Swedish satel- lite named Freja with launch scheduled for August 1992 on a Chinese Long March rocket. The magnetometer controller utilized a custom microprocessor designed at APL with the Genesil silicon compiler. The processor evolved from our experience with an older bit-slice design and two prior single chip efforts. The architecture of our microprocessor greatly lowered software development costs because it was optimized to provide an interactive and extensible pro- gramming environment hosted by the target hardware. Radiation tolerance of the microprocessor was also tested and was adequate for Freja's mission-- 20 kRad(Si) total dose and very infrequent latch-up and single event upset events. 1 Introduction The Johns Hopkins University Applied Physics Laboratory (APL) has developed a micro- processor that is well suited to one-of-a-kind embedded applications especially in satellite instrument control. The chip has been qualified for use in a magnetometer instrument for the Swedish Freja satellite. The processor's language directed architecture reduced Freja software costs because the flight hardware served as its own development system. Thus, unlike traditional interpreted programming languages like Basic, Lisp, or Smalltalk, our Forth language development system was fully supported on the embedded flight proces- sor. Performance was also equivalent or better than that obtained by other microprocessors programmed in languages like C with traditional cross-compilers and development systems.
    [Show full text]
  • Space Station Freedom Data Management System Growth and Evolution Report
    NASA Technical Memorandum 103869 Space Station Freedom Data Management System Growth and Evolution Report R. Bartlett, G. Davis, T. L. Grant, J. Gibson, R. Hedges, M. J. Johnson, Y. K. Liu, A. Patterson-Hine, N. Sliwa, H. Sowizral, and J. Yan N93-15k77 (NASA-TM- I03869) SPACE STATION FREEDOM DATA MANAGEMENT SYSTEM GROWTH ANO EVOLU TIr}N REPORT (NASA) Uncl as September 1992 66 P G3/17 0178407 National Aeronautics and Space Administration Z NASA Technical Memorandum 103869 Space Station Freedom Data Management System Growth and Evolution Report T. L. Grant and J. Yan, Ames Research Center, Moffett Field, California September 1992 RIASA National Aeronauticsand Space Administration Ames Research Center MoffettField, CaJifomia94035-1000 The Study Team The Data Management System (DMS) analysis team Digital Equipment Corporation, Moffett Field, CA consists of civil servants and contractors at NASA Ames Roger Bartlett Research Center, Information Sciences Division. Prof. Joanne Bechta Dugan provided the reliability Intelligent Systems Technology Branch, Ames analysis of the DMS network reported in appendix B; she Research Center, Moffett Field, CA used the HARP code and the work was sponsored by Gloria Davis Langley Research Center (LaRC). Members of the Failure Terry Grant Tolerance/Redundancy Management Working Group Bob Hedges provided network failure information and preliminary Y. K. Liu models that aided our study of the failure tolerance of the Dr. Ann Patterson-Hine DMS network. Nancy Sliwa We also acknowledge the following individuals for Sterling Federal Systems, Inc., Palo Alto, CA reviewing early versions of the manuscripts: Dr. Jerry Yah Gregg Swietek (NASA Headquarters), Mike Pasciuto (NASA), Donald Woods (McDonnell Douglas Space Research Institute for Advanced Computational Systems Company (MDSSC)) and George Ganoe Science, Moffett Field, CA (NASA LaRC).
    [Show full text]
  • Inter-Processor and Inter-Computer Communications
    Inter-processor and Inter-computer Communications David Rye :: MTRX3700 Communications :: Slide 1 of 87 Classification . Close-coupled . Loose-coupled . On-board busses . Serial . Backplanes . RS-232 . RS-422 . RS-485 . CAN . Ethernet David Rye :: MTRX3700 Communications :: Slide 2 of 87 Classification . Interface standard: . Software protocol: physical definition of definition of . Connectors . Order and encoding of . Pin assignments the data words being . Voltage levels transmitted (logic encoding) . Flow control . Timing and handshaking . Error detection and correction David Rye :: MTRX3700 Communications :: Slide 3 of 87 Parallel Busses . Single processor . Multi-processor . Bus mastering . Always short – less than 5m, and often much less David Rye :: MTRX3700 Communications :: Slide 4 of 87 Some Parallel Bus Standards . IEEE-488 (HP-IB, GPIB) . S-100 bus (Altair) . Intel Multibus (Intel, Sun). Adopted as IEEE-765 bus . VMEbus (Motorola 68000). Adopted as IEEE-1014 bus . ISA . PCI . PCIe . etc, etc, etc… David Rye :: MTRX3700 Communications :: Slide 5 of 87 Backplanes, sub-racks and enclosures . Backplanes provide electronic connection for bus signals between processor, memory and I/O boards CAMAC VME Bus All are passive backplanes PCIe David Rye :: MTRX3700 Communications :: Slide 6 of 87 Backplanes, sub-racks and enclosures . Sub-racks provide physical mounting and restraint for backplanes and plug-in cards Eurocard subrack and cards 19” subrack David Rye :: MTRX3700 Communications :: Slide 7 of 87 Backplanes, sub-racks and enclosures . Enclosures and cases provide mounting and environmental protection 19” Rack Case Enclosures Floor-standing 19” rack enclosure 19” Desktop case (exploded view) David Rye :: MTRX3700 Communications :: Slide 8 of 87 IEEE-488 Standard (HP-IB1 or GPIB) .
    [Show full text]
  • Ats.T UNIX® SYSTEM V/386 RELEASE4 MULTIBUS® Reference
    ATs.T UNIX® SYSTEM V/386 RELEASE4 MULTIBUS® Reference Manual ·::::\ .. '''\~:::t::. ::· UNIX Software Operation Copyright 1990, 1989, 1988, 1987, 1986, 1985, 1984 AT&T All Rights Reserved Printed in USA Published by Prentice-Hall, Inc. A Division of Simon & Schuster Englewood Cliffs, New Jersey 07632 No part of this publication may be reproduced or transmitted in any form or by any means-graphic, electronic, electrical, mechanical, or chemical, including photocopying, recording in any medium, tap­ ing, by any computer or information storage and retrieval systems, etc., without prior permissions in writing from AT&T. ACKNOWLEDGEMENT Portions of this book have been provided by Intel Corporation. IMPORTANT NOTE TO USERS While every effort has been made to ensure the accuracy of all information in this document, AT &T assumes no liability to any party for any loss or damage caused by errors or omissions or by state­ ments of any kind in this document, its updates, supplements, or special editions, whether such er­ rors are omissions or statements resulting from negligence, accident, or any other cause. AT&T furth­ er assumes no liability arising out of the application or use of any product or system described herein; nor any liability for incidental or consequential damages arising from the use of this docu­ ment. AT&T disclaims all warranties regarding the information contained herein, whether expressed, implied or statutory, including implied warranties of merchantability or fitness for a particular purpose. AT&T makes no representation that the interconnection of products in the manner described herein will not infringe on existing or future patent rights, nor do the descriptions contained herein imply the granting or license to make, use or sell equipment constructed in accordance with this description.
    [Show full text]
  • Irmx Installation and Startup
    iRMX® Installation and Startup RadiSys Corporation 5445 NE Dawson Creek Drive Hillsboro, OR 97124 (503) 615-1100 FAX: (503) 615-1150 www.radisys.com 07-0683-01 December 1999 EPC, iRMX, INtime, Inside Advantage, and RadiSys are registered trademarks of RadiSys Corporation. Spirit, DAI, DAQ, ASM, Brahma, and SAIB are trademarks of RadiSys Corporation. Microsoft and MS-DOS are registered trademarks of Microsoft Corporation and Windows 95 is a trademark of Microsoft Corporation. IBM and PC/AT are registered trademarks of International Business Machines Corporation. Microsoft Windows and MS-DOS are registered trademarks of Microsoft Corporation. Intel is a registered trademark of Intel Corporation. All other trademarks, registered trademarks, service marks, and trade names are property of their respective owners. December 1999 Copyright 1999 by RadiSys Corporation All rights reserved. ii Quick Contents Section I. Choosing Your Installation Chapter 1. Introduction Section II. iRMX Installation Procedures Chapter 2. Installing on iRMX development/target systems that are PC-compatible Platforms with no DOS Chapter 3. Installing on iRMX development/target systems that are PC-compatible Platforms with DOS Chapter 4. Installing on iRMX Development/Target Systems that are Multibus II Platforms Chapter 5. Installing the iRMX III OS on Multibus I Systems Chapter 6. Installing on Windows NT systems used as iRMX development systems Section III. iRMX Getting Started Chapters Chapter 7. DOSRMX Specifics Chapter 8. iRMX for PCs Specifics Chapter 9. Getting Acquainted with the Operating System Chapter 10. Where To Go From Here Section IV. Appendices Appendix A. Installed Directories Appendix B. Limitations Appendix C. Configuration Requirements for PC Platforms Appendix D.
    [Show full text]
  • Graphics Workstation Standards Standards Writers Play a Game of Catch-Up in an Ever Changing Industry
    = -~ -= --- ~ .-.. = --- -.-. -----~---------- - IIITUi'ii1Jfi IIUIJ----- November 1988 niCDI DU - ---- --- - -- .._- Vol. 4, No. 11 -----._ --- -------._.._._--- -- Engineering Workstations Workstation markets Non-Profit Organ ization Workstation displays U.S. Postage PAID Graphics standards Phillipsburg, N. J. Permit No. 187 =Official Monthly Publication of the Society for Information Display IIITUni•Jn I lUll NOVEMBER 1988 niCDI DU VOL. 4, NO. 11 ~ =---==- =-:::::-- --=~== = --=-~ Cover: Engineering workstations are powerful design tools that can also pro­ 5 Editorial vide compelling design environments-as shown in this prize-winning photograph 8 Workstations-new environment, new market by Ken Gatherum of Boeing Computer The engineering workstation-possibly the most influential new Services Richland, fn c. Cheri Scott design tool of the decade-is still evolving in response to (in photo) worked with colleagues market needs and technical advances. Rick Gerald and Jennie DeVine a1 the Weslinghouse Hanford Company to Paul T. Breen design the displayed 3D graphics model of 11 Displays for workstations the Hanford 100-N nuclear reactor's graphite core stack so the reactor's chain Will the color shadow-mask CRT serve for the workstation of reaction can be optimally moderated when tomorrow? Or will some other technology supplant it? operating conditions change. Hugh C. Masterman 15 Graphics workstation standards Standards writers play a game of catch-up in an ever changing industry. Charles Hafemann 18 Sustaining Members 18 Index to Advertisers 19 Software Notes 20 ID Classified Photo: Ken Gatherum Next Month in Information Display 1988 Technology Roundup • CRTs • Flat displays: plasma, EL, LCD • Large displays • Printers Information Display II 188 J : Ollictal Monthly Publtcatton of the Soctely lor Informal ton Otsplay iDrunl•ln 1 iuil ntc;p1 11'1 Editor: Kenneth I.
    [Show full text]
  • Multibus X.25 Controller (Dev4540) Diagnostics Manual Document No
    CONVEX Multibus X.25 Controller ( dev4540) Diagnostics Manual Document No. 760-002730-000 First Edition May 1991 CONVEX Computer Corporation Richardson, Texas USA CONVEX Multibu8 X25 Controller (dev4540) DfognoBtic8 Manual Order No. DHW-239 First Edition © 1991 CONVEX Computer Corporation All rights reserved. This document is copyrighted. All rights reserved. This document may not, in whole or part, be copied, duplicated, reproduced, translated, electronically stored or reduced to machine readable form without prior written consent from CONVEX Computer Corporation (CONVEX). Although the material contained herein has been carefully reviewed, CONVEX does not warrant it to be free of errors or omissions. CONVEX reserves the right to make corrections, updates, revisions, or changes to the information contained herein. CONVEX does not warrant the material described herein to be free of patent infringement. ~. UNLESS PROVIDED OTHERWISE IN WRITING WITH CONVEX COMPUTER CORPORATION (CONVEX), THE EQUIPMENT DESCRIBED HEREIN IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES. THE ABOVE EXCLUSION MAY NOT BE APPLICABLE TO ALL PURCHASERS BECAUSE WARRANTY RIGHTS CAN VARY FROM STATE TO STATE. IN NO EVENT WILL CONVEX BE LIABLE TO ANYONE FOR SPECIAL, COLLATERAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING ANY LOST PROFITS OR LOST SAVINGS, ARISING OUT OF THE USE OR INABILITY TO USE THIS EQUIPMENT. CONVEX WILL NOT BE LIABLE EVEN IF IT HAS BEEN NOTIFIED OF THE POSSIBILITY OF SUCH DAMAGE BY THE PURCHASER OR ANY THIRD PARTY.
    [Show full text]
  • BUS and CACHE MEMORY ORGANIZATIONS for MULTIPROCESSORS By
    BUS AND CACHE MEMORY ORGANIZATIONS FOR MULTIPROCESSORS by Donald Charles Winsor A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Electrical Engineering) in The University of Michigan 1989 Doctoral Committee: Associate Professor Trevor N. Mudge, Chairman Professor Daniel E. Atkins Professor John P. Hayes Professor James O. Wilkes ABSTRACT BUS AND CACHE MEMORY ORGANIZATIONS FOR MULTIPROCESSORS by Donald Charles Winsor Chairman: Trevor Mudge The single shared bus multiprocessor has been the most commercially successful multiprocessor system design up to this time, largely because it permits the implementation of efficient hardware mechanisms to enforce cache consistency. Electrical loading problems and restricted bandwidth of the shared bus have been the most limiting factors in these systems. This dissertation presents designs for logical buses constructed from a hierarchy of physical buses that will allow snooping cache protocols to be used without the electrical loading problems that result from attaching all processors to a single bus. A new bus bandwidth model is developed that considers the effects of electrical loading of the bus as a function of the number of processors, allowing optimal bus configurations to be determined. Trace driven simulations show that the performance estimates obtained from this bus model agree closely with the performance that can be expected when running a realistic multiprogramming workload in which each processor runs an independent task. The model is also used with a parallel program workload to investigate its accuracy when the processors do not operate independently. This is found to produce large errors in the mean service time estimate, but still gives reasonably accurate estimates for the bus utilization.
    [Show full text]
  • Challenge of Ethernet Use in the Automobile Flexible Interfaces and Software Tools Simplify ECU Development
    Challenge of Ethernet Use in the Automobile Flexible Interfaces and Software Tools Simplify ECU Development Already this year, Ethernet will be used as a system network in the first production vehicles. Therefore, the next step is to integrate Ethernet with established technologies in the automotive industry: CAN, FlexRay, LIN and MOST. Functional development tools exist for them, which make it easy for developers to analyze heterogeneous networks. On the Ether- net side, however, only standard tools from office communications exist, but they do not support the special physical layers and IP protocols of the automotive world. Therefore, development and test tools are urgently needed that can be used to analyze and test existing bus systems together with Ethernet networks. But what would be the exact require- ments of these tools? It is already state-of-the-art technology to transmit cam- Challenges of an Automotive Ethernet Test Solution era images in vehicles at 100 MBit/s over a cost-effective, The use of Ethernet in motor vehicles will require rethinking unshielded twisted pair connection. This technology is by developers and test engineers. First, efforts must ad- known as BroadR-Reach, which is standardized by the dress the issue of how to obtain a clear domain architec- OPEN Alliance SIG consortium [1]. The next objective is to ture (Figure 2). In this architecture, the backbone is no lon- use Ethernet as a network for infotainment and driver as- ger a bus system, but rather it is implemented as a switched sistance systems by 2015. Some OEMs predict that Ether- network with multiple full-duplex connections.
    [Show full text]
  • Citrix Virtual Apps and Desktops Netapp Solutions Netapp October 06, 2021
    Citrix Virtual Apps and Desktops NetApp Solutions NetApp October 06, 2021 This PDF was generated from https://docs.netapp.com/us-en/netapp- solutionshttps://www.netapp.com/us/media/nva-1140-design.pdf on October 06, 2021. Always check docs.netapp.com for the latest. Table of Contents Citrix Virtual Apps and Desktops . 1 TR-4854: NetApp HCI for Citrix Virtual Apps and Desktops with Citrix Hypervisor . 1 Citrix Virtual Apps and Desktops TR-4854: NetApp HCI for Citrix Virtual Apps and Desktops with Citrix Hypervisor Suresh Thoppay, NetApp NetApp HCI infrastructure allows you to start small and build in small increments to meet the demands of virtual desktop users. Compute or storage nodes can be added or removed to address changing business requirements. Citrix Virtual Apps and Desktops provides a feature-rich platform for end-user computing that addresses various deployment needs, including support for multiple hypervisors. The premium edition of this software includes tools to manage images and user policies. Citrix Hypervisor (formerly known as Citrix Xen Hypervisor) provides additional features to Citrix Virtual Apps and Desktops compared to running on other hypervisor platforms. The following are key benefits of running on Citrix Hypervisor: • A Citrix Hypervisor license is included with all versions of Citrix Virtual Apps and Desktops. This licensing helps to reduce the cost of running the Citrix Virtual Apps and Desktops platform. • Features like PVS Accelerator and Storage Accelerator are only available with Citrix Hypervisor. • For Citrix solutions, the Citrix Hypervisor is the preferred workload choice. • Available in Long Term Service Release (LTSR; aligns with Citrix Virtual Apps and Desktops) and Current Release (CR) options.
    [Show full text]