淮阴工学院毕业设计(论文)外文资料翻译系部：计算机工程专业：计算机科学与技术姓名：刘海平学号： 10213120外文出处：Digital Avionics SystemsConference,2005. DASC 2005.The 24th附件： 1.外文资料翻译译文；2.外文原文。
注：请将该封面与附件装订成册。
附件1：外文资料翻译译文解决嵌入式OPENGL难题－使标准、工具和APIS能在高度嵌入和安全的环境中一起工作摘要作为定义和表现屏幕图象来说，嵌入式的HMIS正在使用OpenGL来表现API.由于图形加速子系统和商业驱动的出现，这一趋势能被很好的支持。
同时，嵌入的图形工具和软件厂商已经在他们的API中支持OpenGL。
因为其高度的嵌入和关键的安全环境，完整的OpenGL不是一个狭窄的标准。
为了能获得低价格/低功耗的硬件设备和减少获得关键安全证书的驱动的复杂性，必须包含OpenGL的子集。
近些年，移动图形工业已经从定义合适的OpenGL子集的工业联盟的努力中获得利益。
这些子集，或外形,存在于趋向为广泛的不同的嵌入式市场的应用的不同版本提供服务。
它很清楚如此定义明确的标准罐子和将会有一种在嵌入式和关键安全的图形业上的有益的影响，提供空前的便携和简单的HMI程序. 图形工具和软件厂商正在支持新的标准的水平是不清晰的。
对于终端开发者来说，这些要求是非常高的，就像既不支持或很难的保证的API的可靠性。
这篇论文在对厂商和开发者征税方面提出了些建议，获得用户接口和用OPENGL标准来确保工程的成功和HMI软件的广泛调度的建议。
背景图形处理单元（GPUs）在过去 10 年内, 嵌入式的系统经历了基本的变化的平台显示技术。
这些变化已经主要被两个相似技术所控制，使用了OPENGL的显示硬件和高级的以光栅为基础的EGS系统。
平面显示已经在支持嵌入式尺寸和宽度限制方面有了很大的提高。
以光栅为基础的EGS已经在解决增强的方法方面提供了足够的马力，特别是建立在日常的OPENGL硬件上。
那些渲染引擎或图形芯片是处理图形和创建或渲染图形的移动处理设备的一部分。
在桌面系统方面，硬件渲染引擎起处于统治地位，导致了两个高性能的处理器的分离，这两个处理器目前存在于大部分的系统中。
一个是一般计算，一个是处理和显示图形。
GPU的发展已经在很大程度上被较好的游戏能力和好的工作站和桌面图形处理的需求所控制。
GPU技术在嵌入式系统中寻得了一片生存空间，能提供在高级的在线的显示系统中很难或不可能达到的显示能力。
这些嵌入式的GPU被嵌入到不同的桌面式的图形卡片中，是GPU的特征：随身携带的存储器，硬件加速光设备，转换设备，光栅设备。
大型的桌面式图形公司提供有特色的硬件，在军事方面得到了广泛的使用。
一个嵌入式的GPU如下：目前大部分的GPU技术被用到嵌入式的系统中，它已经在桌面式图形加速方面占据一席之地。
对于GPU有个大胆的设想：将其功耗限制在5~15瓦。
这些设计在嵌入式的环境中能提供一个相等的功耗给桌面式或手提式的设备，并能提供一个可用的软件驱动程序。
OpenGL是目前大部分的共同的标准所提供的驱动程序。
作为一个嵌入式标准的OpenGLGPU的出现是伴随着那些新设计的标准而出现的，这些新设计的标准的出现是为了适应能充分利用硬件优势的图形程序的发展。
OpenGL是一个比较底层的应用程序接口，能提供支持2D和3D的几何绘图的函数的软件接口。
一些主要的OpenGL所支持的头文件如下：几何矩阵变换视口和裁剪变换纹理变换图形传递途径状态的管理几何变换缓存这些函数得到了能被GPU执行的逻辑的传递途径所支持。
这个传递途径在三角形、点、线和变换、裁剪颜色、纹理信息方面期望有一个几何规范，这些三角形、点、线和变换、裁剪颜色、纹理信息通常被用来转换几何图形，使这些几何图形能变成一种绘图模式存于帧缓存中。
在较新的GPU中，那些代表标准几何图形处理的固定的函数传递途径已经增强了顶点和像素明暗的操作,能允许更多传递途径函数的可编程性。
应用程序接口同OpenGL类似，是伴随着其它流行的标准而发展起来的，比如Mircrosoft Direct3D,能在GPU传递途径方面提供可以画图的软件接口。
OpenGL是一个经过多年发展的标准的应用程序接口，最初是通过图形工业先锋Silicon Graphics TM的努力。
在模拟、游戏、计算机辅助制造和专业图形处理市场方面，已经获得了广泛的应用。
此外它还成为嵌入式应用的事实上的标准，在许多平台上是非常有用的。
OpenGL还打算提供一个标准接口到多图形绘图设备上，允许一个应用能伴随着厂商在图形芯片的信心而运行。
OpenGL能在嵌入式电子设备市场上成为一个关键的标准，主要归功于其超强的处理能力和跨平台的的特性。
作为一个应用程序接口，OpenGL经历了15年的发展。
当更多的应用去扩展能力途径时，OpenGL的经成功版本的发行，给这个标准带来了更多的需要和更多的复杂性。
OpenGL是一个典型的用驱动体系结构来执行的。
OpenGL给绘图设备封装了一个底层接口，给那些需要使用硬件特性的应用程序提供一个高级的接口。
当OpenGL在发展时，它的驱动程序也随着发展。
为一个桌面式高级的终端图形硬件提供的现代OpenGL驱动使其能轻松地运行上百万条的直线的代码。
嵌入式变量之所以能变得越来越小，主要得益于OpenGL的子集的划分。
OpenGL子集在下一个移动GPU技术的浪潮中是一个关键的技术。
它的目标是更多的集成芯片市场。
OpenGL和移动的GPU在最近几年，一些具有高级绘图技术和低功耗的GPU的移动计算机开始在市场上出现。
这些设备是目前移动技术的一个主要的发展领域，它们的目标是单个的电话、移动游戏系统、PDA、汽车行业、医药行业以及其他的深入的嵌入式的应用。
当移动游戏发掘出其潜在的市场时，移动设备制造商开始从事GPU驱动程序的开发。
通常一个标准的图形应用程序接口，太大或太昂贵而不能在这些设备上得到应用，比如OpenGL，所以检测设备驱动和设备制造商使用这些应用程序接口的子集。
这些提供应用程序接口子集制造商的目标是明确的市场。
这些应用必须被写进带有较小的子集的工作中去。
这通常意味着它们不能被轻易从一个子集环境插入到另一个子集环境中去。
SoC设计的出现是因为明确定义的应用程序接口子集的移动GPU技术的出现。
在SoC设计中，GPU用来和处理器一起使用的，这个处理器可以将数字媒体处理核心封装到一个芯片上。
这样一个设计能被集成到一个很小的、低廉的应用上，比如：手提式医疗设备，电话，自动通信显示等等。
移动的GPU在嵌入式和关健的安全市场有很明显的应用。
通常，在系统设计中大胆的设想和简单的设计是关键因素。
移动GPU技术将在这些领域有很大的影响。
当新类型的设备开始出现并且能提供OpenGL性能的时候，必须从事针对这些设备的潜在的关键安全的OpenGL的开发。
介绍应用程序接口标准化OpenGL对于关键安全系统是一个很好的标准，并且应该被使用，就像API一样快速的发展。
标准化的子集能对OpenGL在关键安全和高度嵌入的环境中的应用起到一个关键作用。
Khronos所定义的OpenGL扩展标准对于OpenGL子集的标准化是一个重要的发展。
Khronos是一个将OpenGL融入到嵌入式和多媒体市场的一个工业联盟。
Khronos 被所有的大型的图形芯片制造商、移动电话制造商和移动软件发展协会所支持。
当清除多余的性能和着重强调简单和小的足迹时，扩展的OpenGL是定义明确的OpenGL 子集，包括移动设备。
用来提供一个需要嵌入式平台的高级图形的有用的子集。
既然全部的OpenGL规范是庞大的而且支持全部规范的图形子集系统是资源透彻的，需要一个定义明确的子集来提供一个对于嵌入应用的目标绘图能力。
扩展的OpenGL就是这样的一个子集。
工具和应用程序接口OpenGL图形开发者使用几个策略去成功创建OpenGL软件，包括以工具为基础的发展和手写代码。
这两种途径都能在系统中利用软件模块性、高层接口的封装性。
比如，一个数字映射库，用户接口库，或在系统中重用的字体渲染库。
这些工具和SDK能使支持的特性的假设成为潜在的OpenGL驱动和图形设备。
如果一个应用是为了适合驱动程序能力被限制的环境中，这些假设当然大部分需要接受挑战。
许多工具使用代码生成来操作。
显示定义被放入了用户接口中，并且这些工具使用代码生成来创建OpenGL软件执行显示操作。
这样OpenGL软件能包含成千上万的直线代码，其中大部分是几何定义。
对于所有的OpenGL环境来说，这个代码的有用性将被限制除非能足够灵活地去考虑所有输出需要支持的OpenGL子集。
除了工具输出限制其灵活性外，如果一个可重用的OpenGL库已经被写入一个特定结构中，比如OpenGL显示列表或标准的glBegin-glEnd范例，它在驱动程序不支持这个范例的平台上将是无用的。
有些技术途径能被用来考虑减轻这些问题。
结论嵌入式OpenGL是一个关键技术，它已经并且将继续被用在关键安全的嵌入式系统中。
从桌面和工作站市场上引来的GPU技术已经被广泛的应用。
使用了OpenGL的新的嵌入式的芯片的出现将增加它的使用领域。
到时功耗、价格、重量的壁垒将被打破。
为了能在所有的应用领域利用OpenGL的优点，OpenGL子集的广泛使用带来了编程和集成方面的挑战。
这些子集代表标准化OpenGL的努力和提供一个共同的可依赖的子集应用。
虽然处理不同的OpenGL子集的方法被使用，但这些方法正经历着性能和复杂性方面的考验。
一个更灵活的方法是考虑几何规范，像数据。
不注意OpenGL和其子集的结果是关键安全应用发展将付出巨大的代价。
当不同的OpenGL环境被需要，或者应用低代价的SoC或移动绘图GPU被需要，必须严厉地审察OpenGL策略以确保以得到便携。
有两种选择：一种是花大代价去重新应用，另一种是利用不同的标准。
参考文献[1] OpenGL ES Safety Critical Profile Specification, V 1.0. The Khronos Group, 2005[2] OpenGL Common/Common-Lite Profile Specification, V 1.0.02, The Knronos Group, 2004[3] Bennet, Paul A., Applications of Display Prototyping and Rehosting Tools to the Development of Simulator, Flight Training Device, and Cockpit Displays, American Institute if Aeronautics and Astronautics, 1997[4] Snyder, Mark I., A Data-based Paradigm for Rapid Development of Advanced Avionics Displays, Proc. Digital Avionics Systems Conference, Indianapolis, IN, 2003[5] Storey, Neil, and Faulkner, Alastair, Data Management in Data Driven Safety-Related Systems, Proc, 20th Systems Safety Conference, Denver, CO., 2002附件2：外文原文SOLVING THE EMBEDDED OPENGL PUZZLE –MAKING STANDARDS, TOOLS, AND APIS WORK TOGETHER IN HIGHLY EMBEDDED AND SAFETY CRITICAL ENVIRONMENTSMark Snyder, Quantum3D, Glendale, AZAbstractEmbedded graphical Human Machine Interfaces (HMIs) are increasingly making use of the OpenGL rendering API as a standard for defining and rendering screen graphics. This trend is supported by the emergence of hardware accelerated graphics subsystems and commercially available driver software. Meanwhile, embedded graphics tool and software vendors have adopted OpenGL in various forms as the rendering API they support. For highly embedded and safety critical environments, however, full OpenGL is not a narrow enough standard. In order to achieve low-cost/low power hardware implementations and reduce driver complexity to achieve safety-critical certification, OpenGL subsets must be embraced.In recent years, the mobile graphics industry has benefited from the efforts of industry consortiums to define capable OpenGL subsets. These subsets, or profiles, exist in various versions intended to facilitate the development of applications for widely differing embedded markets, from cell phone graphics to safety critical high-powered embedded graphics subsystems. It is clear that such well-defined standards can and will have a beneficial impact on the embedded and safety-critical graphics industries, offering unprecedented portability and simplicity for HMI applications. What is not as clear is the level to which graphics tool and software vendors are supporting the new standards. The stakes are high for the end developer, as reliance on API capabilities that are either unsupported or difficult to certify can present serious system integration and certification pitfalls.This paper presents recommendations in such areas as tool selection, standards to levy on vendors and developers, approaches for achieving user interfaces and font rendering using the OpenGL standards, and recommendations to ensure the successful engineering and wide deployment of HMI software.BackgroundGraphical Processing Units (GPUs)Over the past 10 years, display rendering technology for platform embedded systems has undergone fundamental changes. These changes have been driven primarily by two twin technological thrusts –flat-panel display hardware and advanced raster-based EGS systems using OpenGL. Flat panels have enabled an increase in display resolution while still supporting embedded size and weight constraints. Raster based EGS, particularly based on commodity OpenGL hardware, has provided the horsepower to drive the increased resolution.The rendering engine, or graphics chip, is the part of the mobile computing device that processes graphics and creates or renders the display. On the desktop, hardware rendering engines dominate, resulting in two separate high performance processors being present in most systems –one for general computing, and one for processing and displaying graphics. The development of the GPU, has been largely driven by the desire for better video gaming capability, but also by the desire for better workstation and desktop graphical processing.GPU technology has found a niche in embedded systems, providing advanced display capabilities that were difficult or even impossible to achieve in legacy graphical display systems. These embedded GPUs are embedded variants of desktop or laptop graphics cards, featuring GPUs, onboard texture memory, and hardware accelerated lighting, transformation, and rasterization. Offerings featuring hardware from major desktop graphics companies are being widely used in military applications. An embedded GPU is shown in Figure 1.Figure 1. Embedded GPUMost GPU technology deployed in embedded systems today has its roots in desktop or laptop based graphics accelerators. Power consumption for the GPU alone can range from 5 to 15W. These designs can provide power equivalent to a desktop or laptop within an embedded environment, provided the supporting driver software is available. OpenGL is by far the most commonly used standard to supply these drivers.OpenGL as an Embedded StandardThe advent of the GPU has been accompanied by widespread use of new standards designed to facilitate development of graphical applications that take advantage of the hardware. One such lowlevel Applications Programming Interface (API) is OpenGL. OpenGL provides a software interface that supports 2D and 3D definition of geometry and rendering functions. Some of the major functions OpenGL supports include: Matrix-based geometry transformationsViewport and clipping regionsTextured geometryGraphics pipeline state managementGeometry cachingThese functions are supported through a logical pipeline that the GPU implements. The pipeline expects geometry specification in the form of triangles, points, and lines, along with transformation, clipping, color, and texture information used to convert thegeometry into the form rendered into the frame buffer. In newer GPUs, the fixed function pipeline which represents standard methods of processing geometry has been augmented with vertex and pixel shader operations, which allow more programmability of the pipeline functions. APIs like OpenGL, along with other popular standards such as Microsoft Direct3D, provide software interfaces to draw graphics in the GPU pipeline. The GPU pipeline for OpenGL is shown in Figure 2, where the blue API bubble on the left represents OpenGL.Figure 2. OpenGL PipelineOpenGL is a standardized API that has evolved over many years, initially through the efforts of graphics industry pioneer Silicon GraphicsTM. It has achieved widespread adoption in the simulation, gaming, CAD, and professional graphics markets, and is the de-facto standard for embedded applications. It is widely available on many platforms. OpenGL is also meant to provide a standard interface to multiple graphics rendering devices, allowing an application to run with confidence on graphics chips from multiple vendors. It is a key standard in the embedded avionics market due to its power and cross platform nature.OpenGL as an API has undergone much growth in the past 15 years or so. As more classes of applications sought to exploit its capabilities, successive versions of thestandard have evolved, bringing more calls and more complexity to the standard. OpenGL is typically implemented using a driver architecture. OpenGL drivers encapsulates a low-level interface to the rendering hardware, and presents a high-level interface to applications that need to use the hardware’s featur es. As OpenGL has grown, so have its drivers. A modern OpenGL driver for a desktop high-end graphics card can easily run into millions of lines of code. Embedded variants can be smaller, depending on what subset of OpenGL they support. OpenGL subsets are a key technology in the next wave of mobile GPU technology, targeted for more integrated markets.OpenGL and Mobile GPUsIn the last few years, mobile computers featuring advanced rendering technology using low-power GPUs have begun to appear on the market. These devices, targeted for cell phone, mobile game systems, PDAs, automotive uses, medical uses, and other deeply embedded applications, are currently one of the major development areas in mobile technology. As mobile gaming reaches its market potential, mobile device manufacturers have begun to address the GPU in their device development. Often a standard graphics API, such as OpenGL, is too large or costly to implement on these devices, so COTS driver and device manufacturers rely on subsets of the API. These subsets manufacturers to offer capabilities targeted to specific markets. Applications must be written to work with the smaller subsets, which often means they cannot be ported easily from one subset environment to another.Mobile GPU technology enabled by well-defined API subsets has led to the emergence of System On Chip (SoC) designs. In a SoC design, the GPU is combined with the processor to encapsulate a complete general purpose and digital media processing core on a single chip. Such a design can be integrated into very small, low cost applications such as handheld medical equipment, cellular phones, automotive telematics displays, etc.Mobile GPUs have an obvious application in embedded and safety-critical markets. Oftentimes, power consumption, weight, and simplicity of design are key factors in system design, and mobile GPU technology will have a big impact in these areas. Asentirely new classes of devices begin to emerge and offer OpenGL capabilities, the potential usage of OpenGL by safety-critical applications targeting these devices must be addressed.RecommendationsEmbracing API StandardizationWhile OpenGL is a good standard for safety criticalsystems and should be used, it has grown large as an API. Standardized subsets provide a key to using OpenGL in the safety-critical and deeply embedded environments.The OpenGL ES standard by the Khronos Group is an important development in standardized special purpose subsets of OpenGL. Khronos is an industry consortium designed to foster the adoption of OpenGL into embedded and multimedia markets. Khronos is supported by all major graphics chip manufacturers, mobile phone manufacturers, and the mobile software development community. OpenGL ES is a well-defined subset of OpenGL that is designed to provide a capable subset for advanced graphics on demanding embedded platforms, including mobile devices while eliminating redundant capability and stressing simplicity and small footprint.. Since the full OpenGL specification is large and graphics subsystems that support the full spec are resource intensive, a well-defined subset is required to provide a target rendering capability for embedded applications. OpenGL ES is that subset.Tools and APIsOpenGL graphics developers typically employ several strategies to successfully create the OpenGL software to draw screens, including tool-based development and hand-code. Both approaches can make use of software modularity, encapsulating higher level interfaces, such as a digital map library, user interface library, or font rendering library into SDK’s for reuse in the system. These tools and SDKs may make assumptions about supported features of the underlying OpenGL driver and graphics hardware. If a goal of the application is to be portable to environments where driver capability may be limited, these assumptions will almost certainly need to be challenged.Many tools operate using code generation to generate code representing a display definition. Display definitions are entered into a user interface, and the tool then employs code generation to create OpenGL software implementing the display [3]. Such OpenGL software can encompass tens or even hundreds of thousands of lines of code, most of it devoted to geometry specification. Usefulness of this code for all OpenGL environments may be limited unless its code generation is flexible enough to take into account all OpenGL subsets the output might need to support. The code generation approach is illustrated in Figure 4.In addition to tool output limiting flexibility, if a reusable OpenGL library has been written to rely on certain constructs, such as OpenGL display lists or the standard glBegin-glEnd paradigm, it will not be useful on platforms where the driver does not support this paradigm. There are some technical approaches that can be considered to alleviate some of these problems.ConclusionsEmbedded OpenGL is a key technology that has been and will continue to be used on safety-critical embedded systems. GPU technology borrowed from the desktop and workstation markets has largely been used for these applications. The advent of new embedded chipsets employing OpenGL will increase this usage and potentially extend it into new areas where cost, power, and weight barriers are being broken down.In order to take advantage of OpenGL in all these application areas, the widespread usage of OpenGL subsets presents a programming and integration challenge. Subsets, such as the OpenGL ES Safety-Critical profile from the Khronos group, represent efforts to standardize OpenGL and provide a common subset applications can rely on.Software approaches to handling differing OpenGL subsets can be employed, but these approaches can suffer performance and complexity issues. A more flexible approach is to consider geometry specification as dataThe result of failing to pay attention to OpenGL and its subsets can be costly for a safety-critical application development. When portability to differing OpenGL environments is desired, or the ability to employ low cost SoC or mobile rendering GPUs is needed, the OpenGL strategy must be rigorously scrutinized to ensure such portabilitycan be achieved. The alternative is costly rework of the application to address differing standards.References[1] OpenGL ES Safety Critical Profile Specification, V 1.0. The Khronos Group, 2005[2] OpenGL Common/Common-Lite Profile Specification, V 1.0.02, The Knronos Group, 2004[3] Bennet, Paul A., Applications of Display Prototyping and Rehosting Tools to the Development of Simulator, Flight Training Device, and Cockpit Displays, American Institute if Aeronautics and Astronautics, 1997[4] Snyder, Mark I., A Data-based Paradigm for Rapid Development of Advanced Avionics Displays, Proc. Digital Avionics Systems Conference, Indianapolis, IN, 2003 [5] Storey, Neil, and Faulkner, Alastair, Data Management in Data Driven Safety-Related Systems, Proc, 20th Systems Safety Conference, Denver, CO., 2002Email Addresses Mark Snyder, msnyder@24th Digital Avionics Systems ConferenceOctober 30, 2005。