The interface specification and implementation internals of a program. module for geometric
misra c 2012 rule 20.7 解析 -回复
misra c 2012 rule 20.7 解析-回复Misra C 2012规则20.7主要涉及禁止使用带有不匹配类型信息的参数（参数传递），并提出了一系列相关要求和建议。
本文将逐步解析该规则，从其背景、目的、规则内容、实施方法等方面进行详细阐述。
一、背景和目的在C语言编程中，函数参数传递是常见的操作。
参数的类型信息对于编译器在编译和链接期间进行类型检查和匹配非常重要。
然而，在某些情况下，可能会存在参数传递中类型信息不匹配的问题，这会引发潜在的错误和不确定行为。
为了避免这种情况的发生，Misra C 2012规则20.7被提出。
该规则的目的是通过明确禁止使用不匹配类型信息的参数，以减少由此产生的潜在错误和不确定性，提高代码的可靠性和可维护性。
二、规则内容Misra C 2012规则20.7的具体内容包括以下几点：1. 禁止使用参数传递时类型信息不匹配的情况。
2. 禁止使用任何具有指针类型的参数来绕过类型匹配。
这些禁止使用的情况包括但不限于以下情形：1. 可调用函数与原型不匹配，例如类型不同的参数传递。
2. 使用强制类型转换来绕过类型匹配。
3. 在函数指针中传递类型不匹配的参数。
三、实施方法为了遵守Misra C 2012规则20.7，开发人员可以采取以下几个实施方法：1. 确保传递给函数的参数与函数原型中的参数类型完全匹配，包括类型和数量。
2. 避免使用强制类型转换来解决参数类型不匹配的问题，而是采用合适的数据类型或优化函数设计。
3. 尽量避免使用函数指针中传递类型不匹配的参数，如果必须使用，应当仔细考虑类型转换的合理性和安全性。
此外，对于不匹配类型信息的参数，可以考虑使用其他合理的方法来替代，如结构体、联合体等。
四、规则的优点与挑战Misra C 2012规则20.7的实施有助于提高代码的可靠性和可维护性，减少由于参数传递中类型信息不匹配引起的错误和不确定性。
遵守该规则可以帮助开发人员在编译和链接期间及时发现潜在的类型不匹配错误，减少后期调试和维护成本。
译文GMW3172
General Specification Electrical/Electronic GMW3172General Specification for Electrical/Electronic Component Analytical/Development/Validation (A/D/V) Procedures forConformance to Vehicle Environmental, Reliability, Durability, and Performance Requirements Version 电子零件通用标准汽车环境，靠得住性，耐久性和大体性能要求分析/开发/验证程序 1 Summary of Critical Information 概述The information provided in section one is a summary of the critical requirements for Validation. Detailed explanation of each test or analysis is provided starting in section two. 第一部份是验证要求的概述。
第二部份详细的说明了每一个实验或分析的条件。
1.1 How To Use This Document 如何去用那个文件Figure 1 How To UseThisDocumentQuoting Requirements in Documentation.报价要求Example CTS Reliability Paragraph:”The analytical, developmental and validation mandatory tasks identified in GWM3172 must be performed to ensure adequate product maturity by the end of the product development lifecycle. The component shall pass the Design Validation and Product Validation environmentaland durability requirements of GMW3172. These requirements shall be clearly identifiedthrough use of the GMW3172 Coding System resulting from the location of the product in thevehicle. The code for this product is _____________. A product reliability of at least 97%, witha statistical confidence of 50%, shall be demonstrated on test as described within GMW3172 for product subjected to a combination of vibration and thermally induced fatigue. Thedemonstration of 97% Reliability on-Test corresponds to a field reliability of % under theassumption of a Customer Variability Ratio of three. The Test Flows identified in GMW3172must be followed with any exception receiving prior approval before establishing the ADV supplier must attain world-class reliability for this product. The test requirements contained in this document are necessary but may not be sufficient to meet this world-class field reliability requirement. The supplier is responsible for assuring that other actions are taken such that world class field reliability requirements are met.”在GMW3172中分析、开发、验证被强制要求执行是为了确保最终产品的成熟。
ASAM_XCP_Part4-Interface-Specification_V1-1-0
28
2 Interface to an external Seed&Key function
29
3 Interface to an external Checksum function
31
4 Interface to an external A2L decompression / decrypting
DTO
Data Transfer Object
ECU
Electronic Control Unit
ERR
ERRor Packet
EV
EVent Packet
LEN
LENgth
MCD MTA
Measurement Calibration and Diagnostics Memory Transfer Address
I2S Interface Spec
I2S Interface SpecificationAuthor: Geir Drangegedra@Rev. 1.0January 17, 2005This page has been intentionally left blank.Rev. Date Author Description1.0 28/7/04 Geir Drange Specification, first version1.1 17/1/05 Geir Drange RATIO equation correctionContents1 (1)2 (2)2.1I2S R ECEIVER (4)2.2I2S T RANSMITTER (5)3 (6)3.1R ECEIVER (6)3.1.1Resetting (6)3.1.2Transferring data (6)3.2T RANSMITTER (6)3.2.1Resetting (6)3.2.2Selecting transmit data rate (6)3.2.3Transferring data (7)4 (8)4.1G ENERICS FOR BOTH TRANSMITTER AND RECEIVER (8)5 (9)5.1I2S R ECEIVER (9)5.1.1Receiver registers - overview (9)5.1.2RxVersion – Description (9)5.1.3RxConfig – Description (10)5.1.4RxIntMask – Description (10)5.1.5RxIntStat – Description (10)5.1.6Receive sample data – Description (11)5.2I2S T RANSMITTER (11)5.2.1Transmitter registers - overview (11)5.2.2TxVersion – Description (11)5.2.3TxConfig – Description (12)5.2.4TxIntMask – Description (12)5.2.5TxIntStat – Description (13)5.2.6Transmit sample data – Description (13)6 (14)7 (15)7.1W ISHBONE INTERFACE SIGNALS (RECEIVER & TRANSMITTER) (15)7.2I2S R ECEIVER SIGNALS, SLAVE MODE (16)7.3I2S R ECEIVER SIGNALS, MASTER MODE (16)7.4I2S T RANSMITTER SIGNALS, SLAVE MODE (16)7.5I2S T RANSMITTER SIGNALS, MASTER MODE (16)IntroductionThe I2S-bus (Inter-IC Sound bus) is a serial link for transmitting stereo audio between devices in a system. Typical devices that use this bus are: ADC’s, DAC’s, DSP’s, CPU’s etc. The I2S bus was invented by Philips Semiconductor, but is now widely used by several semiconductor manufacturers.The I2S interface core allows a Wishbone master to stream stereo audio to and from I2S capable devices.ArchitectureThe I 2S interface consists of two separate cores, a transmitter and a receiver. Both can operate in either master or slave mode. The I 2S bus has 3 signals:• SCK – clock• WS – word select (left/right channel) • SD – dataThe master generates SCK and WS signals.Figure 1: I 2S Signal DirectionI2S signal timing:Figure 2: I2S Signal Timing2.1 I2S ReceiverThe receiver architecture is shown below.Figure 3: I2S Receiver Block DiagramThe serial to parallel converter receives serial data and stores audio data in the sample buffer. A set of registers define the operating mode of the receiver.The size of the sample buffer is determined by the Wishbone address bus width. Minimum sample buffer size is 16bytes. The sample buffer is addressed by setting the most significant address bit to ‘1’. The sample buffer is divided in two equal parts, lower and upper, and the user will be notified when either is filled with audio data.Master or slave mode is selected by a generic during compile time.2.2 I2S TransmitterThe transmitter architecture is shown below.Figure 4: I2S Transmitter Block DiagramA parallel to serial converter reads audio data from the sample buffer and transmits serial data on the SD line. A set of registers define the operating mode of the transmitter.The size of the sample buffer is determined by the Wishbone address bus width. Minimum sample buffer size is 16bytes. The sample buffer is addressed by setting the most significant address bit to ‘1’. The sample buffer is divided in two equal parts, lower and upper, and the user will be notified when either is emptied of audio data.Master or slave mode is selected by a generic during compile time.3OperationThis chapter contains operational guidelines for the cores.3.1 Receiver3.1.1 ResettingThe receiver is reset by a Wishbone bus reset or by clearing bit RXEN in RxConfig register.3.1.2 Transferring dataIf the receiver is master, set the RATIO bits in RxConfig to required I 2S bit rate. Set RXEN to 1 to enable receiver.3.2 Transmitter3.2.1 ResettingThe transmitter is reset by a Wishbone bus reset or by clearing bit TXEN in TxConfig register.3.2.2 Selecting transmit data rateIn master mode, the RATIO bits in TxConfig must be set to required bit rate. )2(2___+⋅=RATIO clockbus wishbone rate bitThe sample rate depends on the RES (data resolution) and bit rate: 2__⋅=RES ratebit rate sampleRATIO bits can then be calculated by:4 _8_ __⋅⋅⋅⋅−=RESratesampleRES ratesampleclockbuswishboneRATIO3.2.3 Transferring dataFill up the sample buffer with sample data then set the TXEN bit in TxConfig to start data transfer. Using interrupts, the lower or higher sample buffer can be filled up with new data as soon as its content has been transmitted.GenericsThe I2S interface has a number of generics that can be used to tailor the interface for various needs.4.1 Generics for both transmitter and receiver Name Type Range DescriptionDATA_WIDTH Integer 16/32 Wishbone data bus width. If using 16bit bus,some functionality is lost.ADDR_WIDTH Integer 5 - 32 Wishbone addresses bus width. The samplebuffer occupies half the address range.Table 1: Generics for transmitter and receiverRegistersThis section specifies all internal registers of the I 2S interface.5.1 I 2S Receiver5.1.1 Receiver registers - overviewName Address Width Access Description RxVersion 0x00 16/32 R Version registerRxConfig 0x01 16/32 RW Configuration register RxIntMask 0x02 16/32 RW Interrupt mask register RxIntStat0x0316/32RWInterrupt status registerTable 2: Receiver registers5.1.2 RxVersion – DescriptionThe version register allows the SW to read out all the parameters that were used to generate the receiver.Bit # Access Name Description31-16 - Unused 15-13 - Unused12-6 ADRW The value of ADDR_WIDTH 5 MAST 0: The receiver is slave 1: The receiver is master 4 DATW 0: DATA_WIDTH is 16bit 1: DATA_WIDTH is 32bit 3-0R VER I 2S version number = 1Reset Value: RxVersion: Depends on generics5.1.3 RxConfig – DescriptionThe configuration register controls the operation of the receiver. Note that only 16bit data resolution is supported when DATA_WIDTH =16.Bit # Access Name Description 31-22 R - Unused21-16 RW RESSample data resolution. Number of bits that are stored in each audio word in the sample buffer. Valid range is 16 to 32. If the received signal has fewer bits than set by RES, zero padding of LSB’s is used. If the received signal has more bits than set by RES, LSB’s are truncated.15-8 RWRATIO Master mode only:Clock divider for the transmit frequency. The Wishbone bus clock is divided by a factor of (1+RATIO) to generate the serial transmit clock, SCK.7-3 R - Unused2 RSWAP 0: Left channel is stored on even addresses1: Left channel is stored on odd addresses1 RINTEN 0: Interrupt output is disabled1: Interrupt output is enabledRWRXEN 0: Receiver is disabled1: Receiver is enabledReset Value: RxConfig: 0x00005.1.4 RxIntMask – DescriptionSet bit to 1 in the mask register to enable an interrupt source.Bit # Access Name Description 31-16 R - Unused 15-2 R -Unused1 HSBF Higher sample buffer full interrupt mask 0LSBF Lower sample buffer full interrupt maskReset Value: RxIntMask: 0x00005.1.5 RxIntStat – DescriptionA bit in this register is set to 1 when an event occurs. If the corresponding bit in RxIntMask is set to 1, an interrupt is generated (if enabled). Write a 1 to a bit to clear the event. The interrupt signal goes inactive when all events have been cleared.Bit # Access Name Description31-16 R - Unused 15-2 R -Unused1 HSBF Higher sample buffer full 0LSBF Lower sample buffer fullReset Value: RxIntStat: 0x00005.1.6 Receive sample data – DescriptionFormat of data words in receive sample buffer:Bit # Access Name Description31-16 DATH Audio data if resolution is more than 16bits. Unused bits are 0.15-0R DATL Audio data. Bit 0 is LSB.Reset Value: Sample buffer: undefined5.2 I 2S Transmitter5.2.1 Transmitter registers - overviewName Address Width Access Description TxVersion 0x00 16/32 R Version registerTxConfig 0x01 16/32 RW Configuration register TxIntMask 0x02 16/32 RW Interrupt mask register TxIntStat0x0316/32RWInterrupt status registerTable 3: Transmitter registers5.2.2 TxVersion – DescriptionThe version register allows the SW to read out all the parameters that were used to generate the receiver.Bit # Access Name Description31-16 - Unused 15-13 - Unused12-6 ADRW The value of ADDR_WIDTH 5 R MAST0: The transmitter is slave 1: The transmitter is master4 DATW0: DATA_WIDTH is 16bit 1: DATA_WIDTH is 32bit 3-0VER I 2S version number = 1Reset Value: TxVersion: - depends on generics5.2.3 TxConfig – DescriptionThe configuration register controls the operation of the transmitter. Note that only 16bit data resolution is supported when DATA_WIDTH =16.Bit # Access Name Description 31-22 R - Unused21-16 RW RES Sample data resolution. Number of bits that are transmitted from each audio word in the sample buffer. Valid range is 16 to 32.15-8RWRATIOMaster mode only:Clock divider for the transmit frequency. The Wishbone bus clock is divided by a factor of (1+RATIO) to generate the serial transmit clock, SCK. 7-3 R -Unused2 TSWAP 0: Left channel is stored on even addresses 1: Left channel is stored on odd addresses 1 TINTEN 0: Interrupt output is disabled 1: Interrupt output is enabled 0RW TXEN0: Receiver is disabled 1: Receiver is enabledReset Value: TxConfig: 0x00005.2.4 TxIntMask – DescriptionSet bit to 1 in the mask register to enable an interrupt source.Bit # Access Name Description 31-16 R - Unused 15-2 R -Unused1 HSBF Higher sample buffer empty 0RWLSBF Lower sample buffer emptyReset Value: TxIntMask: 0x00005.2.5 TxIntStat – DescriptionA bit in this register is set to 1 when an event occurs. If the corresponding bit in TxIntMask is set to 1, an interrupt is generated (if enabled). Write a 1 to a bit to clear the event. The interrupt signal goes inactive when all events have been cleared.Bit # Access Name Description 31-16 R - Unused 15-2 R -Unused1 HSBF Higher sample buffer empty 0RWLSBF Lower sample buffer emptyReset Value: TxIntStat: 0x00005.2.6 Transmit sample data – DescriptionFormat of data words in transmit sample buffer.Bit # Access Name Description31-16 DATH Audio data if resolution is more than 16bits. If less than 32bit resolution, set MSB’s to zero. 15-0W DATL Audio data. Bit 0 is LSB.Reset Value: Sample buffer: undefinedClocks The I2S interface uses the Wishbone interface clock only.Rates (MHz)Name SourceMax Min Resolution Remarks Descriptionwb_clk_i - - - Must be at least 8times higher thanI2S bit rateSystem clock.Table 4: List of clocksIO Ports7.1 Wishbone interface signals (receiver &transmitter)PortWidth Direction Descriptionwb_ack_o 1 Output Bus cycle acknowledge wb_adr_i 8-32 Input Address buswb_bte_i 2 Input Burst type extension wb_clk_i 1 Input Clockwb_cti_i 3 Input Cycle type identifier wb_cyc_i 1 Input Valid bus cycle wb_dat_i 16/32 Input Data to core wb_dat_o 16/32 Output Data from core wb_rst_i 1 Input Asynchronous reset wb_sel_i 1 Input Select Input wb_stb_i 1 Input Strobewb_we_i 1 Input Write enableTable 5: Wishbone signalsDescriptionSpecification General description 16/32bit slaveSupported cyclesSLAVE, READ/WRITESLAVE, BLOCK READ/WRITESLAVE, Incrementing burst cycle (linear) Data port, sizeData port, granularityData port, maximum operand size Data transfer ordering Data transfer sequencing 16 or 32bit 16 or 32bit 16 or 32bitBig/little endian UndefinedWishbone properties7.2 I2S Receiver signals, slave modeTop level file is rx_i2s_tops.vhd.Port Width Direction Descriptionrx_sd_i 1 Input I2S serial data inrx_ws_i 1 Input Word select signalrx_sck_i 1 Input Serial clockTable: Receiver signals, slave7.3 I2S Receiver signals, master mode Top level file is rx_i2s_topm.vhd.Port Width Direction Descriptionrx_sd_i 1 Input I2S serial data inrx_ws_o 1 Output Word select signalrx_sck_o 1 Output Serial clockTable: Receiver signals, master7.4 I2S Transmitter signals, slave mode Top level file is tx_i2s_tops.vhd.Port Width Direction Descriptiontx_sd_o 1 Output I2S serial data outtx_ws_i 1 Input Word select signaltx_sck_i 1 Input Serial clockTable: Transmitter signals, slave7.5 I2S Transmitter signals, master mode Top level file is tx_i2s_topm.vhd.Port Width Direction Descriptiontx_sd_o 1 Output I2S serial data outtx_ws_o 1 Output Word select signaltx_sck_o 1 Output Serial clockTable: Transmitter signals, masterOpenCores I2S Interface 1/17/2005 Rev 1.017 of 17。
SysLink UserGuide
SysLink UserGuideSysLink User GuideIntroductionThis is the SysLink User's Guide. It provides information about the SysLink product - its architecture, features, concepts and programming tips.SysLink is runtime software and an associated porting kit that simplifies the development of embedded applications in which either General-Purpose microprocessors (GPP) or DSPs communicate with each other. The SysLink product provides software connectivity between multiple processors. Each processor may run either an HLOS such as Linux, WinCE, etc. or an operating system such as SYS/BIOS or QNX. In addition, a processor may also be designated as the master for another slave processor, and may be responsible for controlling the slave processor's execution (including boot-loading the slave).SysLink provides the following services to frameworks and applications:•Processor Manager•Inter-Processor Communication•Utility modulesTerms and AbbreviationsAbbreviation DescriptionHLOS Higher Level Operating SystemRTOS Real Time Operating SystemCCS Code Composer StudioIPC Inter-Processor CommunicationGPP General Purpose Processor e.g. ARMDSP Digital Signal Processor e.g. C64XCGTools Code Gen Tools, e.g. Compiler, Linker, ArchiverFeaturesSysLink provides communication and control infrastructure between multiple processors present on the target platform and is aimed at traditional embedded applications. SysLink comprises of the following sub-components:•System Manager•Processor Manager•Inter-Processor Communication (IPC)•Utility modulesThe target configurations addressed by the SysLink architecture are:•Intra-Processor•Inter-Processor•Processor may be GPP or DSP, running HLOS or SYS/BiosSysLink ScopeProduct structureThe SysLink product is used in conjunction with the IPC product. The product structuring is as shown below:SysLink and Ipc Product structure and partitioning•The common header files for IPC implemented by both the IPC product (on RTOS-side) and the SysLink product (on HLOS-side) are available within ti/ipc package.•The SysLink product, in addition to implementing the HLOS-side of all IPC modules available within the RTOS IPC product, adds the following:•ProcMgr•FrameQ (HLOS & RTOS)•RingIO (HLOS & RTOS)System PurposeSystem InterfaceThe SysLink product provides software connectivity between multiple processors. Each processor may run either an HLOS such as Linux, WinCE, etc. or an RTOS such as SYS/BIOS or QNX. Based on specific characteristics of the Operating system running on the processor, the software architecture of each module shall differ.The SysLink product provides three types of services to frameworks and applications:•System Manager: The System Manager manages system level resources and overall initialization/finalization for the system. It provides a mechanism of integrating and providing a uniform view for the various sub-components in the system. In addition to overall system management, it also includes the System Memory Managersub-component.•Processor Manager: The Processor Manager on a master processor provides control functionality for a slave device.•IPC: IPC modules are peer-to-peer protocols providing logical software connectivity between the processors.•Utility modules: Utility modules provide utility services utilized by the IPCs and ProcMgr.Architecture goals•The architecture aims to provide reusable & portable modules for the sub-components within SysLink.•The architecture is portable to multiple Operating Systems such as:•SYS/BIOS 6•Linux•WinCE•QNX•etc...•The SysLink architecture is modularized in a way to enable clear interfaces and ownership for module definition.•Identical SysLink APIs are provided across all processors and Operating Systems.Architecture OverviewDependenciesThe SysLink product has dependencies on other several other components: On HLOS side:1.Base port: SysLink has a dependency on the base port to the target device.2.OSAL: In user-space, SysLink utilizes the Operating System Adaptation Layer3.Kernel utils: In kernel-space, the SysLink product utilizes the services available within the kernel utils. Thisincludes OSAL services as well as generic utilities such as trace, string functions etc.4.Types: SysLink uses types matching those defined within xdc/std.h available with the xdctools product.5.Configuration: SysLink provides dynamic configuration for all modules in both user-side and kernel-side. For theLinux product, kernel configuration mechanisms shall be used.On SYS/Bios-side:1.SYS/Bios: SysLink depends on SYS/Bios port available on the target device.2.Build: The SysLink product uses xdc build mechanism3.Configuration: SysLink uses XDC configuration.4.XDC runtime: SysLink uses services available within XDC runtime such as trace, asserts etc.SysLink SYS/BIOS Module ArchitectureThe architecture of each module on SYS/BIOS shall follow the following structure:SysLink SYS/BIOS Module ArchitectureEach module (System Manager/Processor Manager/IPC) on SYS/BIOS is a RTSC module. It uses the XDC configure and build mechanism to ensure that the advantages of whole-program optimization are fully utilized. It also makes use of XDC runtime utils, asserts and tracing mechanisms.Each module implements the common C Header interface APIs defined for SysLink.The module additionally defines internal interfaces as required to ensure plug-and-play of different types of implementations of the physical drivers.In SYS/BIOS, all module initialization get plugged into the startup sequence of the Operating System itself. Due to this, users do not need to call specific initialization functions for the modules.SysLink HLOS Module ArchitectureThe architecture of each module on the HLOS shall follow the following structure:SysLink HLOS Module ArchitectureOn the HLOS, the module configuration is done from the kernel-side, by the system integrator at startup. More details on this are given in a later section on Configuration.The HLOS modules use a make-file based build system. They utilize an OSAL on user-side for abstracting OS-specifics from the implementation.In HLOS, the modules are implemented as drivers within the HLOS. The drivers may be statically or dynamically loaded. Each module has one top-level initialization function that must be called only once. This happens as part of the driver loading. SysLink supports multiple applications/clients using the modules simultaneously, and hence internally has all the checks required to ensure that multiple applications attempting system-level actions are controlled. For example, multiple clients attempting to change the state of the co-processor shall not be allowed to disrupt the co-processor state machine. Only the first client to initiate each state change shall be complied with, and other requests ignored. For example, only the first client to call ProcMgr_start() shall actually result in starting the co-processor. Other clients making this call for the same co-processor shall be ignored unless the co-processor had reached the appropriate state from which the 'start' state change can be initiated. The build system supports optionally building all modules into a single driver or having separate drivers for each module.•If all modules are integrated into a single driver, it provides better ease-of-use to customers who do not wish to load separate one or more drivers for each module. For this use-case, the static configuration can be used to decide which modules are included within the build.•If each module is provided as one or more separate drivers, it enables easier plug-ability and allows users to dynamically add new drivers for different hardware/usage without having to modify existing modules.User-kernel Separated Operating SystemsFor such Operating Systems, the APIs shall drop down into the kernel-side.•The core implementation for all modules shall be available on kernel-side. This shall enable provision of both user-side and kernel-side APIs for all modules.•The configuration of the modules shall be done from kernel-side. This shall enable application clients on both kernel and user-sides to directly start using SysLink.•There are two types of configuration: Module system-level configuration and application specific configuration.•The module-level configuration shall happen only once.•The application-level configuration is limited to specific instances of the module (e.g. MessageQ instances) that are created and used by the application. This configuration shall not happen at system initialization time, but shall happen whenever the instance is created by the module. This may happen either from user-side or kernel-side, depending on whether the specific instance is being created from user-side or kernel-side.• A set of Util services shall be designed for the kernel-side, which shall provide OS abstraction and generic utility services, to enable easy porting to other Operating Systems.Flat Memory Operating SystemsFor such Operating Systems, only the kernel-side implementation shall be directly used. The user-side does not need to be ported at all.ModulesSystem ManagerThe Ipc module (System Manager) provides a means of integrating all the individual Processor Managers and IPCs into a single comprehensive product. It also provides management of system resources such as system memory.The basic functionality provided by the Ipc module on all processors includes:•Initialization and Finalization of the SysLink product•This includes internally calling the initialization and finalization functions for the individual modules included in the build, including IPCs and Processor Managers.•Providing memory (for example, shared memory) to the other SysLink modules. This includes interaction with the IPCs and Processor Manager as required.•System configuration•Any system level configuration information is taken by the System Manager.•The Ipc module also consolidates configuration information for other modules to present a unified SysLink view.•The Ipc module on HLOS also configures itself with the information from the slave-side when the slave executable is loaded. This enables the HLOS-side to configure itself with the identical configuration as the slave-side (for example, shared memory configuration). This ensures that the user is not required to modify HLOS-side configuration whenever the slave-side configuration changes.Processor ManagerThe ProcMgr module provides the following services for the slave processor:•Slave processor boot-loading•Read from or write to slave processor memory•Slave processor power managementThe Processor Manager (Processor module) shall have interfaces for:•Loader: There may be multiple implementations of the Loader interface within a single Processor Manager. For example, COFF, ELF, dynamic loader, custom types of loaders may be written and plugged in.•Power Manager: The Power Manager implementation can be a separate module that is plugged into the Processor Manager. This allows the Processor Manager code to remain generic, and the Power Manager may be written and maintained either by a separate team, or by customer.•Processor: The implementation of this interface provides all other functionality for the slave processor, including setup and initialization of the Processor module, management of slave processor MMU (if available), functions to write to and read from slave memory etc.SysLink ProcMgr ArchitectureAll processors in the system shall be identified by unique processor ID.As per need, a Hardware Abstraction Layer (HAL) shall be internally used to abstract hardware-specific details from generic implementation. This shall enable easier port to different underlying hardware.Types of slave executable loadersSysLink ProcMgr module is designed to support multiple types of loaders for the slave executable. Two loader types, supporting COFF and ELF formats are provided as part of the SysLink release, although they may not be supported on all platforms.Additional points to note:•The config.bld file has been updated to build the above mentioned targets for both COFF and ELF •For the ELF targets in the config.bld, the following additional linker options need to be specified:•--dynamic•-retain=_Ipc_ResetVector•Note that these linker options are automatically added to the generated linker command file for ELF executables when the user's .cfg script containseModule('ti.syslink.ipc.rtos.Syslink');, which is recommended.•Note that the extension of generated ELF executables has an 'e' in it, e.g. notify_omap3530dsp.xe64P as compared to the corresponding COFF executable, which is notify_omap3530dsp.x64P•On Platforms with multiple slaves:•The current ELF loader only supports sequential loading of the slaves.•One slave must be fully loaded and started before the load & start of the next slave is commenced. Parallel load/start is not supportedInter-Processor Communication ProtocolsThe Inter-Processor Communication (IPC) Protocols supported by SysLink are generally defined by TI's IPC product. They include:•Notify•MessageQ•ListMP•GateMP•HeapBufMP•HeapMemMPIn addition, SysLink currently supports two additional forms of IPC tailored for multimedia frameworks:•FrameQ (typically used for raw video data)•RingIO (typically used for audio data)All IPC modules have the following common features:•Instances of the IPC are identified by system-wide unique names•On HLOS-side, each IPC has a <Module>_setup() and <Module>_destroy() API that initializes/finalizes the IPC module. IPC-specific configuration may be provided to the <IPC>_setup() call.•An instance of the IPC shall be created with a <Module>_create() and deleted with <Module>_delete() API. A system-wide unique name is used to create and delete the IPC instance•<Module>_open() API is used to get a handle to the instance that can be used for further operations on the IPC instance. The handle can be relinquished through a call to <Module>_close().•Further calls to the IPC depend on the type of IPC.•The configuration of IPC and their physical transports is either dynamic or static as decided by the system integrator, and the Operating System on each processor. Where XDC configuration is supported, someconfiguration is possible through static configuration.•Each IPC module supports enabling trace information for debugging. Different levels of trace shall be supported.•Some IPCs support APIs to provide profiling information.The architecture of each IPC module follows the generic module architecture described in the earlier sections. For some IPC modules, there may be different implementations of the IPCs transports/drivers depending on the physical link supported and chosen on the device.As per need, a Hardware Abstraction Layer (HAL) shall be internally used to abstract hardware-specific details from generic implementation. This shall enable easier port to different underlying hardware.NotifyThe Notify module abstracts physical hardware interrupts into multiple logical events. It is a simple and quick method of sending up to a 32-bit message.The Notify IPC provides the following functionality:•Initialize and configure the Notify component•Register and un-register for an event.•Multiple clients can register for same event•Clients may be processes or threads/tasks•Callback function can be registered with an associated parameter to receive events from remote processor •All clients get notified when an event is received•Notification can be unregistered when no longer required•Send an event with a value to the specified processor.•Multiple clients can send notifications to the same event•Events are sent across to the remote processor•32-bit payload value can be sent along-with the event•Receive an event through registered callback function.•Event IDs may be prioritized.•0 <-> Highest priority•(Max Events - 1) <->Lowest priority•If multiple events are set, highest priority event is always signaled first•Disable/enable eventsNotify component may be used for messaging/data transfer if:1.Only 32-bit information (payload) needs to be sent between the processors.2.Prioritization of notifications is required. For example, one low priority event (e.g. 30) can be used for sendingbuffer pointers. A higher priority event (e.g. 5) can be used to send commands.3.The notification is to be sent infrequently. Notify module allows the user to specify, when sending an event,whether it wishes to spin till the previous event (for the same event number) has been cleared by the other side, or send the event and potentially lose it.1.If the waitClear option is chosen, if multiple notifications for the same event are sent very quickly insuccession, each attempt to send a specific event spins, waiting till the previous event has been read by the other processor. This may result in inefficiency.2.If the waitClear option is not chosen, the application protocol must not use the payload value being sent alongwith the notification. This is because since there is no wait for the other side to clear the previous event, the payload will get overwritten. Also, if this option is used, the application protocol must be able to withstand 'lost' events. i.e. it may receive only one event notification even if the same event has been sent multiple times.4.Multiple clients need to be able to register for the same notification event. When the event notification isreceived, the same notification with payload is broadcast to all clients registered for that event.Reserved EventsOut of total available events some are reserved for use by different modules for special notification purposes. Following is the list of events that are currently reserved by different modules:Module Event IdsFrameQBufMgr0FrameQ1MessageQ(TransportShm)2RingIO3NameServerRemoteNotify4Notify_sendEvent calling context•Applications should not call Notify_sendEvent from ISR context.•When Notify_sendEvent is called with waitClear as TRUE, it spins waiting for the receiving processor to clear the previous event for the same event ID.•Due to this, if Notify_sendEvent is called from ISR context, it may result in high interrupt latency.•The receiving processor may be occupied in higher priority activities due to which it may not be able to process the event in a deterministic amount of time.•If Notify_sendEvent is called from ISR context, this may result in the interrupt latency on the sending processor to become non-deterministic, which is not advisable.•This API must not be called under GateMP lock protection to avoid deadlocksMessageQThis component represents queue based messaging.MessageQ has the following features:•Messages of variable length are exchanged between one or more processors.•The messages are sent and received through message queues.•Each Message Queue is identified by a system-wide unique name.• A reader gets the message from the queue and a writer puts the message on a queue. A message queue can have only one reader and many writers. A task may read from and write to multiple message queues.•The client is responsible for creating the message queue if it expects to receive messages. Before sending the message, it must open the queue where message is destined.The MessageQ component may be used for messaging/data transfer if:1.Application requires single reader and one or more writers.2.More than 32-bit information needs to be sent between the processors using application-defined messagestructures.3.Variable sized messages are required.4.Reader and writer operate on the same buffer sizes.5.Messages need to be sent frequently. In this case, the messages are queued and there is no spin-wait for theprevious event to be cleared.6.The ability to wait when the queue is empty is desired. This is inbuilt within the MessageQ protocol, and no extraapplication code is required. If MessageQ_get() is called on an empty queue, it waits till a message is received. If Notify is used, the application must register the callback, or wait on a semaphore that is posted by the application's notification callback function.7.It is desired to have the ability to move the Message Queue between processors. In this case, theMessageQ_open() on other processors internally takes care of locating the queue, and the application code sending messages to this queue does not need to change.ListMPThe ListMP module provides multi-processor doubly-linked circular linked list (ListMP) between multiple processors in the system. Features of the ListMP module include:•Simple multi-reader, multi-writer protocol.•Instances of ListMP objects can be created and deleted by any processor in the system.•Each instance of the ListMP is identified by a system-wide unique string name.•To use the ListMP instance, client opens it by name and receives a handle.•Elements can be put at the tail of the list, removed from head of the list•APIs are also available for inserting & removing elements at/from an intermediate location•To peek into list contents, APIs are available for list traversal.•The APIs are protected internally using Gate.•ListMP does not have any inbuilt notification mechanism. If required, it can be built on top using Notify module.•Buffers placed into the ListMP need to be from shared memory. This includes buffers allocated from Heap, as well as those mapped using Dynamic Memory Mapping.ListMP component may be used for messaging/data transfer if:1.Application requires multiple writers and multiple readers.2.The application wishes to perform out-of-order processing on received packets. This is not possible withMessageQ or with Notify. With ListMP, the reader may traverse the shared list and choose any buffer within the list to be removed. However, this is possible only when 'shared' ListMP is used, i.e. ListMPSharedMemory is used. If fast queues are used (hardware assisted), then list traversing may not be possible.3.Making a specific buffer as high priority is desired. The sender to an ListMP can make a specific buffer/messageas high priority by pushing it to the head of the queue instead of placing it at the end of the queue. APIs are provided to traverse the list and insert element before any specified element in the queue. However, this is possible only when 'shared' ListMP is used, i.e. ListMPSharedMemory is used. If fast queues are used (hardware assisted), then this may not be possible.4.Inbuilt notification is not required. If the application desires flexibility in when notification is to be sent/received,ListMP module can be used. The application may use Notify module to send & receive notifications as per its specific requirements. This may result in better performance and lesser number of interrupts, tuned toapplication's requirements. However, the disadvantage is that additional application code needs to be written for notification, which is present inherently within MessageQ component.5.Reader and writer operate on the same buffer sizes.6.More than 32-bit information needs to be sent between the processors using application-defined messagestructures.7.Variable sized messages/data buffers are required.8.Messages/data buffers need to be sent frequently. In this case, the messages are queued directly. Nonotification/spin-wait for notification is performed.The GateMP module provides the Multi-processor critical section between multiple processors in the system. Depending on the hardware functionality available, it shall be possible to write different types of Gate implementations. For example, GatePeterson is a software multi-processor Gate where h/w support is not available. GateHwSpinlock is a Gate that uses h/w spin-lock feature.GateMP moduleThe Multi-processor Gate module provides the following functionality:•Achieves mutually exclusive access to shared objects (data structures, buffers, peripherals etc.)•Instances of Multi-processor Gate objects can be created and deleted by any processor in the system.•Each instance of the Multi-processor Gate is identified by a system-wide unique string name.•To use the Multi-processor Gate instance, client opens it by name and receives a handle.•Client calls an enter API to achieve exclusive access to the protected region. It blocks/spins till access is granted.•Client calls a leave API to release the critical section.Multi-processor HeapsThe HeapMemMP, HeapBufMP, and HeapMultiBufMP modules configure and manage shared memory regions across processors. The features provided by these modules include:•Support for multiple clients on HLOS and SYS/Bios•Allows configuration of shared memory regions as buffer pools•Support for allocation and freeing of buffers from the shared memory region.•These buffers are used by other modules from IPC for providing inter-processor communication functionality. The Memory APIs, into which the individual modules plug in, provide a uniform view of different memory pool implementations, which may be specific to the hardware architecture or OS on which IPC is ported.This component is based on the IHeap interface in XDC.This module provides a single fixed size buffer pool manager. It manages multiple buffers of one fixed size, as specified while configuring the Heap.This module is similar to the SYS/Bios HeapBuf, however it works off shared memory and ensures the appropriate protection and features to allow other processors to use this Heap to allocate and free buffers.HeapMultiBufMPThis module provides a fixed size buffer pool manager. It manages multiple buffers of some fixed sizes, as specified while configuring the Heap. For example, it would support a pre-configured set of 'n' buffers of size 'x', 'm' buffers of size 'y' etc.This module is similar to the SYS/Bios HeapMultiBuf, however it works off shared memory and ensures the appropriate protection and features to allow other processors to use this Heap to allocate and free buffers.HeapMemMPThis module provides a heap based variable sized memory allocation mechanism.The main difference between this module and the HeapMem available with SYS/Bios, is that the HeapMemSM works off shared memory regions, and also takes into account the fact that other processors would be also using this Heap to allocate and free buffers.FrameQFrameQ is a connecting component designed to carry video frames from one processing component in the system to another. FrameQ is a queue data structure which allows queuing and de-queuing of frames; frame carries all the relevant information for a video frame such as frame buffer pointers (YUV data), frame type (RGB565/YUV420/YUV422 etc.), frame width, frame height, presentation timestamp etc.FrameQ can be implemented to operate across processors/processes boundaries, hiding the nuances of IPC, address translation and cache management etc.FrameQ internally uses a special buffer manager: FrameQBufMgr. The FrameQ module provides the following features:•Single writer, multiple readers•FrameQ instances identified by system-wide unique names.•Frames can be allocated and freed•Duplicate operation allocates and initializes an additional frame which points to the same frame buffer•The frame can be put into the Frame Queue by the writer•Notifications can be set by writer for free buffer available to allocate the frames. For reader, notifications providea capability to minimize interrupts by choosing specific notification type. The notification is configurable basedon threshold and type (ONCE/ALWAYS)•Readers can retrieve frames from the Frame Queue.•Multi-Queue operations are also supported, in which multiple frames can simultaneously be allocated/freed/put/get into multiple channels in each FrameQ, for better multi-channel performance.FrameQ module internally uses the FrameQBufMgr, which provides allocation, free and notification mechanisms for frames.•FrameQBufMgr is configured at create time with all characteristics of the frame, including number of frame buffers, sizes, characteristics etc.•The API to allocate a new frame returns a fully constructed frame as per the configuration done at create time.。
ISO 26262-4
Reference numberISO 26262-4:2011(E)© ISO 2011INTERNATIONALSTANDARD ISO 26262-4First edition2011-11-15Road vehicles — Functional safety —Part 4: Product development at the system levelVéhicules routiers — Sécurité fonctionnelle —Partie 4: Développement du produit au niveau du systèmeISO 26262-4:2011(E)COPYRIGHT PROTECTED DOCUMENT © ISO 2011All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical,including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body in the country of the requester.ISO copyright office Case postale 56CH-1211 Geneva 20 Tel. + 41 22 749 01 11Fax + 41 22 749 09 47E-mail copyright@Web Published in Switzerlandii © ISO 2011 – All rights reservedISO 26262-4:2011(E)Contents PageForeword (v)Introduction ........................................................................................................................................................ v i 1Scope (1)2Normative references (2)3Terms, definitions and abbreviated terms (2)4Requirements for compliance (2)4.1General requirements (2)4.2Interpretations of tables (3)4.3ASIL-dependent requirements and recommendations (3)5Initiation of product development at the system level (3)5.1Objectives (3)5.2General (4)5.3Inputs to this clause (6)5.4Requirements and recommendations (6)5.5Work products (6)6Specification of the technical safety requirements (7)6.1Objectives (7)6.2General (7)6.3Inputs to this clause (7)6.4Requirements and recommendations (7)6.5Work products (10)7System design (10)7.1Objectives (10)7.2General (11)7.3Inputs to this clause (11)7.4Requirements and recommendation (11)7.5Work products (16)8Item integration and testing (16)8.1Objectives (16)8.2General (16)8.3Inputs to this clause (16)8.4Requirements and recommendation (17)8.5Work products (25)9Safety validation (25)9.1Objectives (25)9.2General (25)9.3Inputs to this clause (26)9.4Requirements and recommendation (26)9.5Work products (27)10Functional safety assessment (28)10.1Objectives (28)10.2General (28)10.3Inputs to this clause (28)10.4Requirements and recommendation (28)10.5Work products (28)11Release for production (28)© ISO 2011 – All rights reserved iiiISO 26262-4:2011(E)11.1Objectives (28)11.2General (29)11.3Inputs to this clause (29)11.4Requirements and recommendations (29)11.5Work products (30)Annex A (informative) Overview and document flow of product development at the system level (31)Annex B (informative) Example contents of hardware-software interface (33)Bibliography (36)iv © ISO 2011 – All rights reservedISO 26262-4:2011(E)ForewordISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.ISO 26262-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment.ISO 26262 consists of the following parts, under the general title Road vehicles — Functional safety: Part 1: VocabularyPart 2: Management of functional safetyPart 3: Concept phasePart 4: Product development at the system levelPart 5: Product development at the hardware levelPart 6: Product development at the software levelPart 7: Production and operationPart 8: Supporting processesPart 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysesPart 10: Guideline on ISO 26262© ISO 2011 – All rights reserved vISO 26262-4:2011(E)IntroductionISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although ISO 26262 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered. ISO 26262:a) provides an automotive safety lifecycle (management, development, production, operation, service,decommissioning) and supports tailoring the necessary activities during these lifecycle phases;b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive SafetyIntegrity Levels (ASIL)];c) uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk;d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptablelevel of safety being achieved;e) provides requirements for relations with suppliers.Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. ISO 26262 addresses the safety-related aspects of development activities and work products.Figure 1 shows the overall structure of this edition of ISO 26262. ISO 26262 is based upon a V-model as a reference process model for the different phases of product development. Within the figure:the shaded “V”s represent the interconnection between ISO 26262-3, ISO 26262-4, ISO 26262-5, ISO 26262-6 and ISO 26262-7;the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number of the particular part and “n” indicates the number of the clause within that part.EXAMPLE “2-6” represents Clause 6 of ISO 26262-2.vi © ISO 2011 – All rights reservedISO 26262-4:2011(E)Figure 1 — Overview of ISO 26262© ISO 2011 – All rights reserved viiINTERNATIONAL STANDARD ISO 26262-4:2011(E)© ISO 2011 – All rights reserved1Road vehicles — Functional safety —Part 4: Product development at the system level1 ScopeISO 26262 isintended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E)systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg. ISO 26262 does not addressunique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.Systems andtheir components released for production, or systems and their components already under developmentprior to the publication date of ISO 26262, are exempted from the scope. For further developmentor alterations based on systems and their components released for production prior to the publication of ISO 26262, only the modifications will be developed in accordance with ISO 26262.ISO 26262 addressespossible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems. It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity,flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems.ISO 26262 doesnot address the nominal performance of E/E systems, even if dedicated functional performancestandards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control).This part of ISO 26262 specifies the requirements for product development at the system level for automotive applications, including the following:requirements for the initiation of product development at the system level,specification of the technical safety requirements,the technical safety concept,system design,item integration and testing,safety validation,functional safety assessment, andproduct release.ISO 26262-4:2011(E)2 Normative referencesThe following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.ISO 26262-1:2011, Road vehicles — Functional safety — Part 1: VocabularyISO 26262-2:2011, Road vehicles — Functional safety — Part 2: Management of functional safetyISO 26262-3:2011, Road vehicles — Functional safety — Part 3: Concept phaseISO 26262-5:2011, Road vehicles — Functional safety — Part 5: Product development at the hardware levelISO 26262-6:2011, Road vehicles — Functional safety — Part 6: Product development at the software levelISO 26262-7:2011, Road vehicles — Functional safety — Part 7: Production and operationISO 26262-8:2011, Road vehicles — Functional safety — Part 8: Supporting processesISO 26262-9:2011, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses3 Terms, definitions and abbreviated termsFor the purposes of this document, the terms, definitions and abbreviated terms given in ISO 26262-1:2011 apply.4 Requirements for compliance4.1 General requirementsWhen claiming compliance with ISO 26262, each requirement shall be complied with, unless one of the following applies:a) tailoring of the safety activities in accordance with ISO 26262-2 has been planned and shows that therequirement does not apply, orb) a rationale is available that the non-compliance is acceptable and the rationale has been assessed inaccordance with ISO 26262-2.Information marked as a “NOTE” or “EXAMPLE” is only for guidance in understanding, or for clarification of the associated requirement, and shall not be interpreted as a requirement itself or as complete or exhaustive.The results of safety activities are given as work products. “Prerequisites” are information which shall be available as work products of a previous phase. Given that certain requirements of a clause are ASIL-dependent or may be tailored, certain work products may not be needed as prerequisites.“Further supporting information” is information that can be considered, but which in some cases is not required by ISO 26262 as a work product of a previous phase and which may be made available by external sources that are different from the persons or organizations responsible for the functional safety activities.2 © ISO 2011 – All rights reserved4.2 Interpretations of tablesTables are normative or informative depending on their context. The different methods listed in a table contribute to the level of confidence in achieving compliance with the corresponding requirement. Each method in a table is eithera) a consecutive entry (marked by a sequence number in the leftmost column, e.g. 1, 2, 3), orb) an alternative entry (marked by a number followed by a letter in the leftmost column, e.g. 2a, 2b, 2c).For consecutive entries, all methods shall be applied as recommended in accordance with the ASIL. If methods other than those listed are to be applied, a rationale shall be given that these fulfil the corresponding requirement.For alternative entries, an appropriate combination of methods shall be applied in accordance with the ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with different degrees of recommendation for an ASIL, the methods with the higher recommendation should be preferred. A rationale shall be given that the selected combination of methods complies with the corresponding requirement.NOTE A rationale based on the methods listed in the table is sufficient. However, this does not imply a bias for or against methods not listed in the table.For each method, the degree of recommendation to use the corresponding method depends on the ASIL and is categorized as follows:“++” indicates that the method is highly recommended for the identified ASIL;“+” indicates that the method is recommended for the identified ASIL;“o” indicates that the method has no recommendation for or against its usage for the identified ASIL.4.3 ASIL-dependent requirements and recommendationsThe requirements or recommendations of each subclause shall be complied with for ASIL A, B, C and D, if not stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal. If ASIL decomposition has been performed at an earlier stage of development, in accordance with ISO 26262-9:2011, Clause 5, the ASIL resulting from the decomposition shall be complied with.If an ASIL is given in parentheses in ISO 26262, the corresponding subclause shall be considered as a recommendation rather than a requirement for this ASIL. T his has no link with the parenthesis notation related to ASIL decomposition.5 Initiation of product development at the system level5.1 ObjectivesThe objective of the initiation of the product development at the system level is to determine and plan the functional safety activities during the individual subphases of system development. This also includes the necessary supporting processes described in ISO 26262-8.This planning of system-level safety activities will be included in the safety plan.© ISO 2011 – All rights reserved34 © ISO 2011 – All rights reserved5.2 GeneralThe necessary activities during the development of a system are given in Figure 2. After the initiation of product development and the specification of the technical safety requirements, the system design is performed. During system design the system architecture is established, the technical safety requirements are allocated to hardware and software, and, if applicable, on other technologies. In addition, the technical safety requirements are refined and requirements arising from the system architecture are added, including the hardware-software interface (HSI). Depending on the complexity of the architecture, the requirements for subsystems can be derived iteratively. After their development, the hardware and software elements are integrated and tested to form an item that is then integrated into a vehicle. Once integrated at the vehicle level, safety validation is performed to provide evidence of functional safety with respect to the safety goals.ISO 26262-5 and ISO 26262-6 describe the development requirements for hardware and software. This part of ISO 26262 applies to both the development of systems and subsystems. Figure 3 is an example of a system with multiple levels of integration, illustrating the application of this part of ISO 26262, ISO 26262-5 and ISO 26262-6.NOTE 1 Table A.1 provides an overview of objectives, prerequisites and work products of the particular subphases of product development at the system level.ײ·¬·¿¬·±² ±º °®±¼«½¬ ¼»ª»´±°³»²¬ ¿¬ ¬¸» -§-¬»³ ´»ª»´ìóëÍ°»½·º·½¿¬·±² ±º ¬¸» ¬»½¸²·½¿´ -¿º»¬§®»¯«·®»³»²¬-ìóê׬»³ ·²¬»¹®¿¬·±² ¿²¼ ¬»-¬·²¹ìóèÍ¿º»¬§ ª¿´·¼¿¬·±²ìóçÚ«²½¬·±²¿´ -¿º»¬§ ¿--»--³»²¬ìóïðλ´»¿-» º±® °®±¼«½¬·±²ìóïïͧ-¬»³ ¼»-·¹²ìóéﮬ ìæ Ю±¼«½¬ ¼»ª»´±°³»²¬æ -§-¬»³ ´»ª»´NOTE 2 Within the figure, the specific clauses of each part of ISO 26262 are indicated in the following manner: “m-n”, where “m” represents the number of the part and “n” indicates the number of the clause, e.g. “4-5” represents Clause 5 of ISO 26262-4.Figure 2 — Reference phase model for the development of a safety-related item© ISO 2011 – All rights reserved5NOTE Within the figure, the specific clauses of each part of ISO 26262 are indicated in the following manner: “m-n”, where “m” represents the number of the part and “n” indicates the number of the clause, e.g. “4-5” represents Clause 5 of ISO 26262-4.Figure 3 — Example of a product development at the system level5.3 Inputs to this clause5.3.1 PrerequisitesThe following information shall be available:project plan (refined) in accordance with ISO 26262-2:2011, 6.5.2;safety plan in accordance with ISO 26262-3:2011, 6.5.2;functional safety assessment plan in accordance with ISO 26262-2:2011, 6.5.4; andfunctional safety concept in accordance with ISO 26262-3:2011, 8.5.1.5.3.2 Further supporting informationThe following information can be considered:preliminary architectural assumptions (from external source); anditem definition (see ISO 26262-3:2011, 5.5).5.4 Requirements and recommendations5.4.1 The safety activities for the product development at the system level shall be planned including determination of appropriate methods and measures during design and integration.NOTE The results of planning of the verification activities during design in accordance with 6.4.6 (Verification and validation) and 7.4.8 (Verification of system design) are part of the safety plan while the planning of item integration and testing in accordance with 8.4.2 (hardware/software), 8.4.3 (element integration) and 8.4.4 (item integration) is represented in a separate item integration and testing plan in accordance with requirement 8.4.1.3.5.4.2 The validation activities shall be planned.5.4.3 The functional safety assessment activities for the product development at the system level shall be planned (see also ISO 26262-2).NOTE An example of a functional safety assessment agenda is provided in ISO 26262-2:2011, Annex E.5.4.4 The tailoring of the lifecycle for product development at system level shall be performed in accordance with ISO 26262-2, and based on the reference phase model given in Figure 2.NOTE The project plan can be used to provide the relationship between the individual subphases of product development at the system level and the hardware and software development phases. This can include the integration steps at each level.5.5 Work products5.5.1 Project plan (refined) resulting from requirement 5.4.4.5.5.2 Safety plan (refined) resulting from requirement 5.4.1 to 5.4.4.5.5.3 Item integration and testing plan resulting from requirement 5.4.1.5.5.4 Validation plan resulting from requirement 5.4.2.5.5.5 Functional safety assessment plan (refined) resulting from requirement 5.4.3.6 © ISO 2011 – All rights reserved6 Specification of the technical safety requirements6.1 ObjectivesThe first objective of this subphase is to specify the technical safety requirements. The technical safety requirements specification refines the functional safety concept, considering both the functional concept and the preliminary architectural assumptions (see ISO 26262-3).The second objective is to verify through analysis that the technical safety requirements comply with the functional safety requirements.6.2 GeneralWithin the overall development lifecycle, the technical safety requirements are the technical requirements necessary to implement the functional safety concept, with the intention being to detail the item-level functional safety requirements into the system-level technical safety requirements.NOTE Regarding the avoidance of latent faults, requirements elicitation can be performed after a first iteration of the system design subphase.6.3 Inputs to this clause6.3.1 PrerequisitesThe following information shall be available:functional safety concept in accordance with ISO 26262-3:2011, 8.5.1; andvalidation plan in accordance with 5.5.4.6.3.2 Further supporting informationThe following information can be considered:safety goals (see ISO 26262-3:2011, 7.5.2);functional concept (from external source, see ISO 26262-3:2011, 5.4.1); andpreliminary architectural assumptions (from external source, see ISO 26262-3:2011, 8.3.2).6.4 Requirements and recommendations6.4.1 Specification of the technical safety requirements6.4.1.1 The technical safety requirements shall be specified in accordance with the functional safety concept, the preliminary architectural assumptions of the item and the following system properties:a) the external interfaces, such as communication and user interfaces, if applicable;b) the constraints, e.g. environmental conditions or functional constraints; andc) the system configuration requirements.NOTE The ability to reconfigure a system for alternative applications is a strategy to reuse existing systems. EXAMPLE Calibration data (see ISO 26262-6:2011, Annex C) is frequently used to customise electronic engine control units for alternate vehicles.© ISO 2011 – All rights reserved76.4.1.2 The consistency of the preliminary architectural assumptions in ISO 26262-3:2011, 8.3.2 and the preliminary architecture assumptions in this subphase shall be ensured.6.4.1.3 If other functions or requirements are implemented by the system or its elements, in addition to those functions for which technical safety requirements are specified in accordance with 6.4.1 (Specification of the technical safety requirements), then these functions or requirements shall be specified or references made to their specification.EXAMPLE Other requirements are coming from Economic Commission for Europe (ECE) rules, Federal Motor Vehicle Safety Standard (FMVSS) or company platform strategies.6.4.1.4 The technical safety requirements shall specify safety-related dependencies between systems or item elements and between the item and other systems.6.4.2 Safety mechanisms6.4.2.1 The technical safety requirements shall specify the response of the system or elements to stimuli that affect the achievement of safety goals. This includes failures and relevant combinations of stimuli in combination with each relevant operating mode and defined system state.EXAMPLE The Adaptive Cruise Control (ACC) ECU disables the ACC functionality if informed by the brake system ECU that the Vehicle Stability Control functionality is unavailable.6.4.2.2 The technical safety requirements shall specify the necessary safety mechanisms (see ISO 26262-8:2011, Clause 6) including:a) the measures relating to the detection, indication and control of faults in the system itself;NOTE 1 This includes the self-monitoring of the system or elements to detect random hardware faults and, if appropriate, to detect systematic failures.NOTE 2 This includes measures for the detection and control of failure modes of the communication channels (e.g.data interfaces, communication buses, wireless radio link).b) the measures relating to the detection, indication and control of faults in external devices that interact withthe system;EXAMPLE External devices include other electronic control units, power supply or communication devices.c) the measures that enable the system to achieve or maintain a safe state;NOTE 3 This includes prioritization and arbitration logic in the case of conflicting safety mechanisms.d) the measures to detail and implement the warning and degradation concept; ande) the measures which prevent faults from being latent [see 6.4.4 (Avoidance of latent faults)].NOTE 4 These measures are usually related to tests that take place during power up (pre-drive checks), as in the case of measures a) to d), during operation, during power-down (post-drive checks), and as part of maintenance.6.4.2.3 For each safety mechanism that enables an item to achieve or maintain a safe state the following shall be specified:a) the transition to the safe state;NOTE 1 This includes the requirements to control the actuators.b) the fault tolerant time interval;NOTE 2 In-vehicle testing and experimentation can be used to determine the fault tolerant time interval.8 © ISO 2011 – All rights reservedc) the emergency operation interval, if the safe state cannot be reached immediately; andNOTE 3 In-vehicle testing and experimentation can be used to determine the emergency operation interval.EXAMPLE 1 Switching off can be an emergency operation.d) the measures to maintain the safe state.EXAMPLE 2 A safety mechanism for a brake-by-wire application, which depends on the power supply, can include the specification of a secondary power supply or storage device (capacity, time to activate and operate, etc.).6.4.3 ASIL Decomposition6.4.3.1 If ASIL decomposition is applied during the specification of the technical safety requirements it shall be applied in accordance with ISO 26262-9:2011, Clause 5 (Requirements decomposition with respect to ASIL tailoring).6.4.4 Avoidance of latent faults6.4.4.1 This requirement applies to ASILs (A), (B), C, and D, in accordance with 4.3: if applicable, safety mechanisms shall be specified to prevent faults from being latent.NOTE 1 Concerning random faults, only multiple-point faults have the potential to include latent faults.EXAMPLE On-board tests are safety mechanisms which verify the status of components during the different operation modes such as power-up, power-down, at runtime or in an additional test mode to detect latent faults. Valve, relay or lamp function tests that take place during power up routines are examples of such on-board tests.NOTE 2 Evaluation criteria that identify the need for safety measures preventing faults from being latent are derived in accordance with good engineering practice. The latent fault metric, given in ISO 26262-5:2011, Clause 8, provides evaluation criteria.6.4.4.2 This requirement applies to ASILs (A), (B), C, and D, in accordance with 4.3: to avoid multiple-point failures, the multiple-point fault detection interval shall be specified for each safety mechanism implemented in accordance with 6.4.4 (Avoidance of latent faults).6.4.4.3 This requirement applies to ASILs (A), (B), C, and D, in accordance with 4.3: to determine the multiple-point fault detection interval, the following parameters should be considered:a) the reliability of the hardware component with consideration given to its role in the architecture;b) the probability of exposure of the corresponding hazardous event(s);c) the specified quantitative target values for the maximum probability of violation of each safety goal due tohardware random failures (see requirement 7.4.4.3); andd) the assigned ASIL of the related safety goal.NOTE The use of the following measures depends on the time constraints:periodic testing of the system or elements during operation;on board tests of elements during power-up or power-down; andtesting the system or elements during maintenance.© ISO 2011 – All rights reserved9。
具体讲解接口的定义(国外英文资料)
Understanding Interface Definitions: A Guide to Interactions in the DigitalWorldWhat Exactly Is an Interface?Types of Interfaces1. Hardware Interfaces:2. Software Interfaces:3. User Interfaces (UI):User interfaces are the visual and interactive aspects of a device or application that allow users to engage with it. A welldesigned UI can make the difference between a pleasantuser experience and a frustrating one. Examples include the screens on your smartphone, the dashboard of your car, or the control panel on a microwave.The Importance of StandardizationStandardization is key to the effectiveness of interfaces. Standards ensure that different systems can work together regardless of their origin or manufacturer. Organizationslike the International Organization for Standardization (ISO) and the Institute of Electrical and Electronics Engineers (IEEE) play a crucial role in establishing these standards.In ConclusionThe Nuances of Interface Definitions: Exploring the Technical TapestryThe Anatomy of a Software APIEndpoints: These are the specific URLs where the API can be accessed. Endpoints serve as addresses for different services or data that the API provides.Methods: APIs use methods such as GET, POST, PUT, and DELETE to perform operations. These methods define the type of action that can be executed through the API, such as retrieving data or updating it.Parameters: These are the variables that are passed to the API to specify certain actions or filter data. Parameters can be required or optional and are crucial for customizing API responses.Data Formats: APIs exchange data in various formats, such as JSON (JavaScript Object Notation) or XML (eXtensible Markup Language). The choice of format affects the efficiency and readability of the data being transferred.The Role of Protocols in Interface CommunicationTCP/IP: These protocols govern the fundamental architecture of the internet, ensuring that data packets are sent from the correct source to the correct destination.The Challenge of Interface DesignCreating an effective interface is both an art and a science. It requires a deep understanding of user needs, technical capabilities, and design principles. Key considerations include:Usability: An interface must be intuitive and userfriendly. It should minimize the learning curve and provide a seamless experience for the user.Security: Interfaces often handle sensitive data, so they must be designed with security in mind. This includes encryption, authentication, and access control measures.The Future of InterfacesAs technology advances, so too do interfaces. We're witnessing the rise of new interface types, such as: Augmented Reality (AR) Interfaces: AR interfaces overlay digital information onto the physical world, offering a new way to interact with data and environments.In the everevolving landscape of technology, the role of interfaces remains constant—they are the essential translators that enable different parts of our digital world to speak the same language. Understanding their nuances is not just a technical pursuit; it's a journey into the very fabric of our interconnected future.The Subtleties of Interface Definitions: Unveiling the Interconnected WebThe Philosophy Behind Interface DesignInterface design is not merely a technical endeavor; it's an exercise in philosophy. It requires a thoughtful approach that considers the following principles:Consistency: Users should be able to apply what they've learned from one part of an interface to another. Consistency in design helps build a sense of familiarity and trust with the technology.Feedback: Interfaces must provide clear and timely feedback to users. Whether it's a visual cue or a confirmation message, feedback is essential for guiding user actions and building confidence.The Impact of Cultural Differences on Interface DesignWhen designing interfaces for a global audience, cultural differences cannot be overlooked. What may be a standard interaction pattern in one culture could be confusing or even offensive in another. Considerations include:Language: Interfaces must be adaptable to different languages, not just in terms of translation but also in terms of layout, as some languages read from right to left or have different typographical conventions.Symbols and Icons: Visual elements can vary in meaning across cultures. Designers must ensure that icons and symbols are universally understood or culturally adapted.Color: Colors carry different connotations in various cultures. Interface designers must be mindful of color choices to avoid unintended messages.The Intersection of Accessibility and Interface DesignAccessibility is a cornerstone of inclusive interface design. It ensures that people with disabilities can use technology effectively. Key aspects of accessible interface design include:Screen Reader Compatibility: Visual interfaces must be designed with screen readers in mind, using proper HTML tags and ARIA (Accessible Rich Internet Applications) attributesto convey information to users with visual impairments.Contrast and Font Size: Sufficient contrast and adjustable font sizes are critical for users with visual impairments, ensuring that content is readable and accessible.The Evolution of Interface Design: From Static to Dynamic The evolution of interface design has moved from static pages to dynamic, responsive systems. This shift has introduced new challenges and opportunities:Adaptive Interfaces: These interfaces learn from user interactions and adapt over time to better serve individual preferences and needs. This personalization can significantly enhance the user experience.Realtime Data: Modern interfaces often incorporate realtime data streams, providing users with uptothesecond information. Designing for realtime data requires careful consideration of performance and user attention.In the grand tapestry of interface design, each thread represents a choice made designers to create a more connected, accessible, and userfriendly world. As we continue to refine our understanding of interface definitions, we edge closer to a future where technology seamlessly integratesinto our lives, enhancing our experiences and broadening our horizons.。
华为认证英文题库H12-211
Exam : H12-211Title : Huawei Certified DatacomAssociate-Huawei NetworkingTechnology and Device(HCDA-HNTD)Vendor : HuaweiVersion : DEMONO.1 Refer to the graphic. RTA is a PPPoE client, and following transmission of PADI, Server A responds with PADO packets to RTA. Which distribution method is used for sending PADO packets?A.multicastB.broadcastC.unicastD.anycastAnswer: CNO.2 [RTA]acl 2002[RTA-acl-basic-2002]rule deny source 172.16.1.1 0.0.0.0[RTA-acl-basic-2002]rule deny source 172.16.0.0 0.255.0.0Which of the following entries will be matched on the router PTA using the ACL matching routing entries shown above? (multiple choice)A. 192.17.0.0/24B. 172.18.0.0/16C. 172.16.1.0/24D. 172.16.1.1/32Answer: B,DNO.3 Which of the following statements about the Node Segment is wrong?A.Configure the IP address as the prefix on the loopback interface of the node. The Prefix SID of this node is actually the Node SID.B.The Node SID cannot be the same as the node Prefix SIC.Node Segment is used to identify a specific nodeD.Node Segment is a special Prefix SegmentAnswer: BNO.4 Network management hopes to effectively use the IP address of the 192.168.176.0/25 network segment. Now that the company's marketing department has 20 hosts, it is best to allocate the following.Which address segment is given to the marketing department?A. 192.168.176.0/25B. 192.168.176.160/27C. 192.168.176.48/29D. 192.168.176.96/27Answer: DNO.5 Which of the following IPv4 addresses is a Class A address?A. 100.1.1.1B. 192.168.1.1C. 172.16.1.1D. 121.1.1.1Answer: DNO.6 A switch receives a data frame with a VLAN tag, but finds that the MAC address of the data frame cannot be queried in its MAC address table.Then the processing behavior of the data frame by the switch is ().A.The switch broadcasts the data frame to all ports.B.The switch broadcasts this data frame to all access ports.C.The switch will discard this data frameD.The switch broadcasts this data frame to all ports (except the receiving port) in the VLAN that belongs to the data frame.Answer: DNO.7 The network as shown in the following figure, the following configurations exist on the Router A.Which of the following statements are correct? (Multiple Choice) ip route-static 10.0.2.2255.255.255.25510.0.12.2 ip route-static 10.0.2.2 255.255.255.255 10.0.21.2 preference 70A.If the GO/0/1 port is Down, the route that Router A reaches 10.0.0.2 is changed to 10.0.21.2.B.The NextHop that reaches 10.0.2.2 in the routing table of Router A is 10.0.12.2.C.The NextHop that reaches 10.0.2.2 in the routing table of Router A is 10.0.21.2.D.If the GO/0/2 port is Down, the route that Router A reaches 10.0.0.2 is changed to 10.0.12.2. Answer: A,BNO.8 A router has learned two routes for the same network with the same prefix. One route has been learned via OSPF with a metric of 4882, while the other route has been learned via RIPv2 with a metric of 4. Which route (s) will be found in the routing table?A.The RIPv2 route.B.The OSPF and RIPv2 routes.C.The OSPF route.D.Neither of these routes will be found in the routing table.Answer: CNO.9 The Trunk port can allow multiple VLANs to pass, including VLAN4096.A.FalseB.TrueAnswer: ANO.10 Which of the following statement about STP messages is correct? (Multiple choice)A.There are two types of packets in the STP protocol, configure BPDUs and TCN BPDUs.B.When the port is enabled with STP, the switch periodically sends TCN BPDUs from the specified port.C.The BPDU packet is encapsulated in an Ethernet data frame, and the destination MAC address is a multicast MAC address.D.During the initialization process; each switch that enables STP protocol actively sends configuration BPDUs.Answer: A,C,DNO.11 In the process of establishing PPP link, which phase can be directly converted into by the Dead phase?A.AuthenticateworkC.EstablishD.TerminateAnswer: CNO.12 As shown in the broadcast network, OSPF runs on four routers and is in the same area and on the same network segment. OSPF A DR and multiple BDRs will be automatically elected to achieve better backup results.A.WrongB.YesAnswer: ANO.13 As shown in the figure, all three switches run GVRP, create VLAN 10 and VLAN 20 on SWA and SWC, and create them on SWB.VLAN 10. SWB dynamically learned VLAN 20 from SWA and SWC through GVRP. If the port G0/0/1 onthe SWB is modified to be GVRP In the Fixed mode, the following description is correct ().A.Hosts belonging to the same VLAN can continue to communicateB.All hosts cannot communicate with any other hostC.Host A can continue to communicate with HostD.Host B can continue to communicate with Host DAnswer: CNO.14 Which of the following parts does the global unicast address consist of? (Multiple Choice)A.Protocol IDB.Subnet IDC.Global Routing PrefixD.Interface IDAnswer: A,B,DNO.15 The priority of the LAGP protocol is as shown in the figure. Switch A and Switch B adopt link aggregation in LAGP mode, and all interfaces loin the link aggregation group. The maximum number of active ports is set to 3. Which port of switch A is not the active port?A.GO/0/0B.GO/0/3C. G0/0/2D. GO/0/1Answer: BNO.16 The following statement is incorrect (). (multiple choice)A.The priority of each static route can be different.B.By default, the order of route priority is OSPF higher than RIP.C.In VRP, the greater the priority of the routing protocol, the higher the priority of the route.D.If the cost of the route is larger, the priority of the route is higher.Answer: C,DNO.17 On the VRP platform, which of the following methods can you access the previous historycommand?(Multiple Choice)A.Upper cursorB.Left cursorC.Ctrl+PD.Ctrl+UAnswer: A,CNO.18 As shown in the configuration, if the administrator configures OSPF on R1 but R1 cannot learn the routes of other routers, the possible reason is ().(multiple choice)[R1]ospf[R1-ospf-1]area 1[R1-ospf-1-area-0.0.0.1]network 10.0.12.0 0.0.0.255A.This router does not announce the network connecting neighbors when configuring OSPF.B.The router is not configured with authentication, but the neighbor router is configured with authentication.C.The OSPF process ID is not configured when this router is configured.D.The area ID configured by this router is different from the area ID of its neighbor router. Answer: A,B,DNO.19 As the network shown in the following figure, all routers run OSPF. The top of the link is the value of the Cost. What is the path of the RA to the network 10.0.0.8/8?A.60B.70C. 100D. 20Answer: ANO.20 The DHCPv6 server includes the management address configuration flag (M) in the RA message. If the value is 1, which of the following statement is correct?A.Indicates that the client enables DHCPv6 stateful address configuration.B.Indicates that the client enables IPv6 stateless address automatic allocation schemeC.Indicates that the client needs to obtain other network configuration parameters through stateful DHCPv6.D.Indicates that the client needs to obtain other network configuration parameters through stateless DHCPv6.Answer: ANO.21 Refer to the graphic. Two switches have been connected as shown and both support STP. The administrator has configured switch A as a DHCP server and set interface VLANIF1 of switch B to obtain an IP address from switch A.A link failure occurs on port interface G0/0/1 of switch B.What action will occur as a result?A.The two switches will be unable to communicate.B.Switch B will send a DHCP Discovery message to obtain a new IP address.C.Swich B will continue to use the IP address obtained from Switch AD.Switch B will send a DHCP Release message to release the IP address.Answer: CNO.22 Which of the following parameters cannot be used for the advanced access control list?A.Physical interfaceB.Agreement numberC.Destination port numberD.Time rangeAnswer: ANO.23 Two routers have established a point-to-point network using PPP. The administrator has configured the routers to run OSPF in the same area with the same router ID, what will behavior will occur as a result of the configuration?A.The routers will build a neighbor relationship even though both routers are using the same router ID.B.The routers will not send hello packets to each other because they are using the same router IC.The routers will build an adjacency even though both routers are using the same router ID.VRP will notify of a router ID conflict between the two routers.Answer: DNO.24 If the network shown in the following figure is used to make the 1opbacko communication between Router A and Router B through static routes, which of the following command need to enter on Router A?A.A p route-static 1002 2 32 GigabitEthemet 0/0/0B.ip route-static 100220 GigabitEthemet 0/0/0C. a ip route-static 10 02 2 255.255.255.255 10.0.12 2D. 13_ ip route-static 1002 2 255255 255255 100 12 1Answer: CNO.25 The administrator plans to implement a route backup by configuring a static floating route. The correct implementation method is ().A.The administrator needs to configure different protocol priority values for the primary static route and the alternate static route.B.The administrator only needs to configure two static routes.C.The administrator needs to configure different metrics for the primary static route and the alternate static route.D.The administrator needs to configure different TAGs for the primary static route and the standby static route.Answer: ANO.26 Which of the following is the value of the IPv6 multicast address flag field indicates that the multicast address is a temporary multicast address?A.1B.0C.3D.2Answer: ANO.27 Which of the following remote login methods is the safest?A.Stelnet v1B.Stelnet v2C.Stelnet v100D.TelnetAnswer: BNO.28 The following is true about PPP description (). (multiple choice)A.PPP supports multiple network layer protocols, such as IPCP and IPXCP.B.PPP supports bundling multiple physical links into logical links to increase bandwidthC.For the physical layer, PPP supports asynchronous links and synchronous links.D.PPP is not scalable and cannot be deployed on an Ethernet link.E.PPP supports plaintext and ciphertext authenticationAnswer: A,B,C,ENO.29 In the RSTP protocol, the PIA mechanism requires that the link between two switching devices be in point-to-point full-duplex mode.A.FalseB.TrueAnswer: BNO.30 Which packet does OSPF use to acknowledge received LSU packets?A.LSACKB.LSUC.LSRD.LSAAnswer: ANO.31 Which of the following statements are correct? (Choose two)A.A single broadcast domain exists between SWA and SWB.A single collision domain exists between RTA and SWC.C.A single collision domain exists between SWA and SWD.A single broadcast domain exists between SWA and SWAnswer: A,CNO.32 Refer to the graphic. Two peering routers are running RIP. RTA is using RIPv2 to advertise its routes, while RTB is using RIPv1 to advertise the route 1.1.1.1/32. The administrator configures "RIP version 2 multicast" for interface G0/0/1 of RTB. How will the route 1.1.1.1/32 appear in the the IP routing table of RTA?A.This route will appear in the IP routing table of RTA as 1.0.0.0/8.B.This route will appear in the IP routing table of RTA as 1.0.0.0/32.C.This route will appear in the IP routing table of RTA as 1.0.0.0/24.D.This route will not appear in the IP routing table of RTAnswer: BNO.33 Which of the following regarding Frame Relay DLCI are correct? (Choose three)A.DLCI is locally significantB.The range of DLCI value that can be used is from 16-1007C.The same DLCI can be configured on different physical interfacesD.DLCI is allocated by DTEAnswer: A,B,CNO.34 Refer to the graphic. In the private network, RTA dynamically assigns a public address from the address pool to hosts without port translation. Host C wishes to access the public network while pool addresses are assigned to Host A and Host B.What will occur as a result?A.All hosts will have access to the public network through pool address swapping.B.Host C will be unable to forward traffic over the public network.C.The first public address will be allocated to Host C, and Host A will be forced offline.D.The last public address will be allocated to Host C, and Host B will be forced offline. Answer: BNO.35 A trunk port can send both tagged data frames and unlabeled data frames.A.ErrorB.CorrectAnswer: B。
JTAG协议规范1149.1和1149.7
Doing More with Less – An IEEE 1149.7 Embedded Tutorial : Standard for Reduced-pin and Enhanced-functionality Test Access Port andBoundary-Scan ArchitectureAdam W LeyASSET InterTech, Inc. Richardson TX, USAAbstractIEEE Std 1149.7 offers a means to reduce chip pins dedicated to test (and debug) access while enhancing the functionality of the Test Access Port (TAP) as a complementary superset of the original IEEE Std 1149.1 (JTAG). Extended features such as hot-plug immunity, power management, optimization of scan throughput, access to instrumentation, and access to custom technologies provide welcome improvements for debug. Further, the boundary-scan architecture is bolstered to ensure full support for test. This important advancement in test and debug interfaces is well suited for access to multiple cores on SOC or multiple die in SIP or POP.1.IntroductionIn the 1980s, the Joint Test Action Group (JTAG) was formed to address a growing concern about diminishing test access to chips on boards due to the adoption of surface-mount assembly methods and ongoing miniaturization of chip packages. In 1990, their efforts culminated in the ratification of IEEE Std 1149.1 – Standard Test Access Port and Boundary-Scan Architecture. While 1149.1 was firmly rooted in the needto solve the problems of board test, as exemplified by the provision for boundary scan, the proponents of the standard realized the need for a generalized means of low-level access to components on boards and in systems that would suit a wide range of uses. As a result, the 1149.1 test access port (TAP), as specified, has met this need.In fact, even before the ink was dry, the 1149.1 TAP was being exploited for purposes beyond board test. In these early days, its utility was deployed to support access to chips for in-circuit emulation (debug), albeit often with additional pins for proprietary signals. Somewhat later, the ubiquity of the 1149.1 TAP was exploited in a normative sense for in-system configuration of programmable devices by way of IEEE Std 1532. Later still, use of the 1149.1 TAP as a debug interface was standardized by NEXUS 5001 (although still requiring additional signaling for many cases). Today, for the same reasons of utility and ubiquity, the 1149.1 TAP is considered the most likely means of access to chips that support embedded instruments per P1687 (informally known as Internal JTAG or IJTAG).Notwithstanding the exceptional merits of the 1149.1 TAP, ongoing industry momentum toward greater miniaturization and still more integration led some to the conclusion that a makeover was needed [1]. In particular, they proposed to enhance its functionality and utility in applications debug, but also to reduce pins to be better suited to multi-core/ multi-die architectures. IEEE Std 1149.7 [2, 3, 4, 5] has been developed to meet these needs [6, 7, 8, 9, 10, 11, 12].1.1What is IEEE 1149.7IEEE 1149.7 is a standard for a test access port and associated architecture that offers reduced pins and enhanced functionality. With regard to pin reduction, whereas the conventional 1149.1 TAP (TAP.1) requires at least four signals (with a fifth, for test reset, being optional), the reduced-pin 1149.7 TAP (TAP.7) requires only two signals (with the possibility for encoding the optional test reset function onto these). Further, with regard to functionality enhancement, it is expected that, in many cases, extended signaling needs for uses such as applications debug can be met on no more than two pins. Even while delivering these benefits, 1149.7 has taken great pains to preserve the investment that the industry has made in 1149.1 for chips and on boards. Particularly, 1149.7 adopts the entirety of the 1149.1 boundary-scan architecture to fully support board test and in-system configuration. Further, 1149.7 does not replace 1149.1, but rather adapts it and extends it, building upon its foundation and legacy. For example, as illustrated in Figure 1, an 1149.1 chip can be adapted easily to provide a TAP.7. As well, TAP.7s can coexist with TAP.1s on boards and, in some cases, even on the same board-level TAP connections.“before”“after”Figure 1—Adaptation of 1149.1 to 1149.71.2IEEE 1149.7 Key ObjectivesThe key objectives for 1149.7 fall broadly into three categories – system architecture, applications debug, and legacy infrastructure (to include test).Benefits for system architecture derive from the appropriate accommodation of multiple on-chip embedded TAP Controllers (EMTAPC), the reduction of pins, the adoption of glue-less star topology, independence from CPU/debug technology, and provisions for power management. Where intellectual property (IP) blocks may each contain EMTAPCs, multiples of these may be accommodated on a complex system-on-chip (SOC). While reduced pin count has inherent value with respect to miniaturization, consider as well that, in combination with the star topology, fewer pins better support the new 3D packaging methodologies such as system-in-package (SIP). These typically involve the stacking of die as shown in Figure 2; conversely, a daisy-chaining implementation is not only more difficult but also is not 1149.1 compliant. Of course, the same can be said for package-on-package (POP). Further, independence from particular CPU/debug technologies supports similar integrations even where chips may incorporate CPU IP from multiple sources. Facilities that permit the test logic to enter power-down modes support increasingly aggressive power management requirements.Figure 2—Star topology for a 3-die SIPFor applications debug, the TAP.7 provides advanced capability that reduces or eliminates the need for signaling beyond the two wires. Extensions provided include robust hot connect, increased throughput by way of scan optimization, higher operating frequency, and transport of background instrumentation data and/ or custom protocols. Of course, independence from CPU/debug technology also accrues here because uniform tool sets can support chips with heterogeneous CPUs.Finally, as concerns the legacy infrastructure, the objectives are two-fold – first, honor 1149.1 by preserving the test infrastructure that has been built up around it and on which the industry depends; and second, maintain a level of compliance such that existing intellectual property in chips, on boards, and in debug and test systems (DTS) can be adapted at low cost.2. Overview/ How it WorksAt the highest level of abstraction, 1149.7 provides for a chip-level TAP.7 Controller that bridges the conventional 1149.1-accessible System Test Logic (STL) to the four (five) or two (three) wires of the chip-level TAP.7 (the test reset signal is optional in either case). The STL has its own 1149.1 chip-level TAP Controller (CLTAPC) and all of the associated test logic architecture, including a chip-level boundary-scan register and related EXTEST, PRELOAD, and SAMPLE instructions.Seeking to extend 1149.1 in a compatible fashion, 1149.7 starts with the observation that the TAP Controller (TAPC) at the core of 1149.1 is a two-wire control means, even in the conventional series topology, as shown in Figure 3.TCK TDITDOTMSFigure 3—Conventional series topology, highlighting the starwiring for TCK/TMSPer 1149.1 convention, the starred TCK/TMS can only advance the TAPC state, which in turn invokes TDI/TDO for scan operations, but, absent instruction register scans, does not change the mode of the test logic. Thus, the key concept of 1149.7 continues with the observation that control extensions might be overlaid on sequences of TAPC states (more details on this later).Thus, 1149.7 adds its own commands and registers on which the other layers of extended functionality are based. These additional layers add scan formats, direct addressability, packetization of scan data (TMS, TDI, and/ or TDO information) onto the TMS wire (hence, re-designated TMSC), and finally packetization of non-scan information onto TMSC to provide for transport of background and/ or custom data.As such, 1149.7 supports a number of capability classes (six in number, designated as T0 - T5). So the TAP.7 Controller is configurable to support the required capability for a given implementation. The primary functional units are illustrated in Figure 4 and are designated as follows: Advanced Protocol Unit (APU), Extended Protocol Unit (EPU), Pin-Sharing Logic (PSL), and Reset and Selection Unit (RSU). The manner in which these items are invoked (or not) for given capability classes will be described in subsequent sections.TDI(C)nTRST EPU TAP.7TDO(C)TCK(C)TMS(C)TAP.7 ControllerFigure 4—Notional view of the 1149.7 architecture2.1 Capability classesRegardless of which capability class is implemented, a given TAP.7 must implement all of the mandatory features of its own class as well as those of all lower-numbered classes (T0 < T5). The classes are generally considered in two primary groupings: those which extend 4-wire operation (T0 – T3) and those which provide the reduced-pin, 2-wire operation (T4 – T5).T0–foundationAs the foundation of all TAP.7 capabilities, T0 begins with 1149.1-Specified behavior, such that the T0 STL is 100 percent compliant to 1149.1 including provisions for the mandatory chip-level boundary-scan architecture. With 1149.7 T0, the chip-level device identification register becomes mandatory.Of the TAP.7 Controller elements shown in Figure 4, only the RSU is permitted as an option; the other items are reserved for higher classes.Where the RSU is implemented, this would be done, as for any other class, to permit Escape Sequences and/ or Selection/Deselection Alerts to be available to manage the sharing of TAP.7 signaling across technologies and topologies. When the TAP.7 Adapter TAPC (ADTAPC) is deselected, the CLTAPC will be parked. These topics will be addressed in greater detail with T3 where the RSU becomes mandatory.Of particular note, even where the chip has multiple EMTAPCs, as might be the case for a complex SOC that implements a mix of several core IP blocks, the T0 STL shall provide 1149.1-Specified behavior from the Test-Logic-Reset TAPC state. 1149.7 identifies several means by which EMTAPCs can be selected under the control of the CLTAPC. A further method is defined for managing multiple die-level TAPCs in a similar manner for SIP. T1–commands and registersWith T1, the 1149.7 mechanism providing extended control by way of TCK/TMS is invoked to access 1149.7 commands and registers. These functions pertain to the EPU as illustrated in Figure 4. So, the EPU block of the TAP.7 Controller is present for T1. Otherwise, excepting the RSU, as for T0, all other blocks are reserved for higher classes.As described earlier, the extended control mechanism operates without disruption to the conventional 1149.1 TAPC state machine. Rather, it uses a particular state sequence, which is benign to normal 1149.1 operations, to initiate 1149.7-defined action.The state sequence of interest is known as a zero-bit DR scan (ZBS) and these are to be operated only while all of the CLTAPCs in the selected topology operate BYPASS or IDCODE so as to ensure that they do not disrupt normal system operation. In fact, ZBS detection is validated only when no IR scans have intervened since the last occurrence of the Test-Logic-Reset TAPC state.The progression of states that is recognized as a ZBS is illustrated in Figure 5.ScanCapture-DRExit1-DRExit2-DRUpdate-DRShift-DRPause-DR1110111abFigure 5—Zero-bit scan (ZBS)There are actually two different paths, labeled as “a” and “b” in Figure 5, that can implement a ZBS. In either case, the state sequence of interest is defined as follows: from the Select-DR-Scan TAPC state, proceed to the Update-DR TAPC state without passing the Shift-DR TAPC state. From the Test-Logic-Reset TAPC state, wherein the ZBS count is set to zero, the extended control mechanism is initiated when at least two ZBSs are detected before a subsequent non-zero-bit DR scan, which locks the ZBS count. A locked ZBS count of two provides access to the 1149.7 commands and registers. Locked ZBS counts greater than two access higher control levels that will not be detailed here.Once the ZBS count is locked, and a control level set, it is only unlocked when the control level is exited by entry to either the Select-IR-Scan or Test-Logic-Reset TAPC states or by certain 1149.7 commands and events that are used to synchronize T4 and T5 operations.At control level 2, commands are recognized, without the use of TDI/TDO pins, by counting the number of TCK(C)ticks in the Shift-DR TAPC state for two scans that immediately follow the completion of the non-zero-bit DR scan that locked the ZBS count. Each of these two primary command words is coded in 5 bits, ensuring that these counts need not exceed 31. All commands include two such parts for a total code length of 10 bits. In most cases, the command and register operations are concluded in these two parts but in some (only three) special cases a third part (a DR scan of a length determined by the control register addressed by the command) is required.T1 mandates a given minimum set of such commands and the registers that they address. Additionally, some commands, registers, and associated functions are optional, notably those that invoke directed test reset generation and request for functional reset.Additionally, T1 provides for power management through four modes of power control for the test logic. These four modes are: allow power down if TCK stops at logic one for more than 1 ms, allow power down if TCK stops at logic one for more than 1 ms in the Test-Logic-Reset TAPC state, allow power down if the device is in the Test-Logic-Reset TAPC state, and do not allow power down (the test logic is always powered).Given that a power-down mode is supported, the test logic is directed to resume powered operation when the Run-Test/Idle TAPC state is forced for at least 100 ms and at least 3 TCK(C) ticks.T2–scan formatsThe 1149.7 scan formats are introduced in T2. A T2 TAP.7 supports JScan0 – JScan2; other scan formats are reserved for higher classes.Of the TAP.7 Controller elements shown in Figure 4, for T2, as for T1, only the EPU is mandatory with the RSU permitted as an option; the other items are reserved for higher classes. For T2 versus T1, the EPU adds the commands and registers associated with the scan formats. As regards the function of these scan formats, JScan0 provides 1149.1-Specified behavior while JScan1 provides for the deselection of the CLTAPC in favor of a 1-bit scan path (so-called Super Bypass) that is active for IR scans as well as DR scans and JScan2 provides for activation/deactivation of the Super Bypass according to the value of an 1149.7 register.A T2 TAP.7 can opt either for JScan0 or JScan1 as its startup behavior. The latter case is described as providing hot-plug immunity since it should permit live connection (or disconnection) of the TAP.7 signals to be non-disruptive to the test logic.T3–direct addressabilityFinally, with T3, the star topology (4 wire), as in Figure 6, is supported. This comes by adding the means for direct addressability and the JScan3 scan format that provides for scans to star-4 topologies.Figure 6—Star-4 topologyOf the TAP.7 Controller elements shown in Figure 4, T3 adds the RSU as a mandatory element in addition to the EPU. For T3 versus T2, the EPU adds the commands and registers associated with direct addressability. Note that for T3, the TDI and TDO signals are re-designated as TDIC and TDOC, respectively.Concerning the RSU for T3, it is required to implement Escape Sequences for reset and for selection/ deselection and may optionally implement Selection and Deselection Alerts. Escape Sequences involve the detection and counting of a number of edges on TMS(C) driven while TCK(C) is held at logic 1. The count of such edges determines the action to be taken in response to the Escape Sequence. Alerts are specific predefined sequences of 128 bits as driven on TMS(C).The resource invoked for support of direct addressability is the TAP.7 Controller Address (TCA), as shown in Figure 7. The values corresponding to DEVICE_ID are inherited from the 1149.1 device identification register capture value for the CLTAPC. The assignment of the NODE_ID is made by some implementation-specific means that is not defined by 1149.7. The NODE_ID serves to distinguish multiple TAP.7s on a given topology branch where they are of the same device type.Figure 7—TAP.7 Controller Address (TCA)A key provision required to facilitate scans to the star-4 topology is the prevention of drive conflict on TDOC. The JScan3 format is managed so that when multiple TAP.7 Controllers are requested to participate, then drive on TDOC will be inhibited.As discussed in more detail in 4.1, test applications require the ability to coordinate the simultaneous entry of all devices of interest into and/ or through the Capture-xR, Update-xR, and Run-Test/Idle TAPC states. At first glance, the star topology would seem not to support this requirement. But in addition to the JScan3 scan format, T3 adds the Scan Selection Directives (SSD) to deal with this matter. The SSDs make use of Pause-xR TAPC states as parking states to which simultaneous scan captures aredirected and from which simultaneous scan updates are directed. Scan shift operations, as necessitated by the star topology are done on a device-by-device basis and are both directed from and to the Pause-xR TAPC states. T4–packetization of scan data (2-pin scan formats)With T4, a number of additional scan formats are added to support the advanced protocol, which is operated on two pins. The TCK/TMS pins are re-designated as TCKC/TMSC, respectively. The corresponding star-2 topology is illustrated in Figure 8. Note that TMSC is bidirectional.TMSCTCKCFigure 8—Star-2 topologyOf course, these additions require the provision of the APU of Figure 4. As well, since the TDIC/TDOC pins are optional since they are not used for 2-pin operation, where they are provided the PSL also becomes an option. Where a T4 TAP.7 does not provide the TDIC/TDOC pins in any configuration, it is described as narrow and designated as T4N. Where a T4 TAP.7 does have a configuration that provides the TDIC/TDOC pins, it is described as wide and designated as T4W.One of the more basic scan formats that supports the advanced protocol is OScan1. The serialization of the scan packet for OScan1 is illustrated in Figure 9. As shown, the TDI bit information is inverted. Also, for each cycle in which the TDO bit appears it is driven from the selected device in the target system back to the DTS.TCKCTMSC stateFigure 9—Scan packet serialization – OScan1Other scan formats in the OScan series provide for optimizations in which the scan packets omit bits that can be known to carry no significant information. An example worth noting is the OScan7 format which is optimized for downloads from the DTS to the target system. For OScan7, as illustrated in Figure 10, only the TDI bit information is included in the packets sent during Shift-xR TAPC states.TCKC nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDITMSC Shift-xRShift-xRShift-xRstateFigure 10—Scan packet serialization – OScan7Further performance optimization that can be obtained for T4 is by invoking falling-edge sampling for TMSC which, presuming hold times still can be met, delivers a degree of improvement in setup times that would allow the TCKC frequency to be increased (perhaps doubled).T5–transport of non-scan data (2-pin mode)At the top of the classes, T5 offers the capability to interleave transfers of non-scan data among the scan transfers. This is referred to as transport and has two variants – background data transport (BDX) and custom data transport (CDX).Both types of transport can use any combination of Run-Test/Idle, Pause-xR, and Update-xR TAPC states after which to insert transport packets. The distinction is that, whereas BDX has fixed allocation of I/O bandwidth available to the chip-level data channel, CDX has a custom allocation of I/O bandwidth as determined/ defined by the chip-level unit.2.2 Selection hierarchyWhile some aspects of the selection hierarchy have been described above, some additional detail is warranted as it is a key aspect of the 1149.7 system architecture.In general, where selection is enabled within the hierarchy, those items not selected are effectively offline/ parked and respond only to particular selection requests on the TAP.7 signaling. Those that are selected are online and respond to the TAP.7 signaling according to the protocols for which they are configured.Five levels in the selection hierarchy are elaborated below. For each level of the hierarchy, one or more selection mechanisms may pertain. - TechnologyWhere the 1149.7 technology can be placed offline, the TAP.7 signaling can be shared with other technologies- TopologyW here the constituent 1149.7 devices can be placed offline (a function required for T3 and above), the TAP.7 signaling can be shared among any topology branches, whether series, star-2, or star-4 - Adapter (i.e., ADTAPC)1149.7 devices comprising a selected topology branch will share TAP.7 signaling and, where the topology branch is star-2 or star-4, a given device may be selected for a given operation- Chip (i.e., CLTAPC)For a selected ADTAPC, the CLTAPC may be offline and will require selection when it must be operated- Core (i.e., EMTAPC)For a selected CLTAPC, given EMTAPC(s) of interest may be offline and will require selection when it (they) must be operated3.Implications for DebugIn many respects, 1149.7 was defined by and for the debug community. Thus, many of the implications, considerations, and supporting features have already been addressed in the elaboration of the basic 1149.7 functions as described above. Still some of these bear specific mention in this context.3.1Debug considerationsChief among the considerations for debug are ease and efficiency. Of course, these unfold across multiple dimensions and are often intertwined.EaseThe highest degree of visibility and control is required to drive the analysis tools that can get to the bottom of thorny problems that arise in today’s multi-threaded, multi-core, real-time embedded systems. 1149.7 promises to bring value to this equation by consolidating debug access for multiple cores onto a smaller number of chip pins.Other features tending toward ease of debug are the hot-plug immunity and system interrogation.EfficiencyCertainly 1149.7 enjoys a performance boost relative to 1149.1 with its various optimizations for scan throughput and its ability to improve link utilization by using otherwise idle non-scan states to transport background instrumentation data.3.2Debug featuresAs one would expect, 1149.7 brings a wealth of features to address debug ease and efficiency.Access consolidationSeveral aspects of the 1149.7 system architecture provide for access consolidation: management of EMTAPCs (T0), star topology (T3), pin reduction (T4N/T5N), and capability for the TAP.7 to transport background data and custom protocols (T5). All of these result in making debug instrumentation more accessible and, hence, easier to use. Hot-plug immunityLive connection without system disruption is vital and is enabled by the offline at startup (T3 or any with RSU) and Super Bypass at startup (T2) features. System interrogationA method for topology interrogation (T3) is provided and enumeration of controllers can be made by undirected allocation of Controller IDs (CID) (T3), as in Figure 11. These features allow the system architecture to be discovered by the debug tool at connect time.Each participating chip drives its AT[n]on wired-OR basis (logic 1 inactive)All supporting chips without CID participate;chips with a CID do not participate.For each participating chip, its aliasing targetAT[35:0] = TCA[34:0] + 0Final n?Each chip that detects that itsAT[n] != TDO drops outNext nThe chip that matched all 36 bitsof its AT to all 36 bits of TDOwins and gets the CIDFigure 11—CID Allocation, Undirected Optimization of scan throughputPerhaps above all, 1149.7 offers a great number of opportunities to optimize scan throughput. Super Bypass (T2) results in shorter scan chains for series topology. Star topology (T3) offers direct addressability and, hence, scan operation in only the target of interest.Advanced protocol (T4) offers still further improvements based on scan packet optimization on one hand and falling-edge timing (and thereby clock doubling) on the other.Improved link utilizationBDX and CDX (T5) allow the link to be used for transport of instrumentation data even during non-scan states, which would otherwise be idle.4.Implications for TestWhile 1149.7 primarily has been developed for the benefit of applications debug, it also has gone to considerable lengths to ensure that the test legacy of the original 1149.1 is honored. Among the several test-related provisions are the scan selection directives that ensure update/ capture/ run-test synchronization and the definition of suitable test languages.4.1Test considerationsWhile 1149.7 does not change radically how 1149.1 boundary scan/ test is being used today, there are some new considerations for test that arise with the 1149.7 architecture. Primary among these are the divergence inscan-state sequencing and series/star interoperability. Other considerations worth mention are hierarchical navigation, power control, and large-system applications. Scan-state sequencingThe typical test application has requirements for scan-state sequencing that necessitate coordination of application of stimuli across multiple distinct components (with their own boundary-scan registers) on a given unit under test (UUT). Consider the case where several components have distinct 3-state outputs on a shared wire junction. If the distinct output control cells in each of these components were not updated in a coordinated fashion, a contention could be present on the shared wire. The simplest means of such coordination is to ensure that all components pass simultaneously through the Update-DR TAPC state. As well, while it might not be necessary in some cases, the coordination of the acquisition of response generally also is required (or at least preferred). At the least, where specific response to given stimuli is required, the distinct responses for each component involved must all be acquired before the applied stimulus is changed. Here again, the simplest means for such is to ensure that all components pass simultaneously through the Capture-DR TAPC state (in fact, simultaneity may be strictly required in some special cases).Some test applications, such as the testing of advanced digital networks per IEEE Std 1149.6, have an additional requirement that all components participating in such testing must pass simultaneously through the Run-Test/Idle TAPC state.Conventional scan sequencing for test applications presuming series topology is illustrated in Figure 12.Run-Test-Idle1Select-DR-ScanCapture-DRExit1-DRExit2-DRUpdate-DRShift-DRPause-DR110111Figure 12—Scan-state sequence (conventional) for testapplications, series topologyThis conventional scan-state sequence can be broken down as follows:- (in yellow) all components on the UUT (series topology) pass through the Capture-DR TAPC state wherein responses (to a previously applied stimulus) are acquired in concert- (in red) all components on the UUT (series topology) enter and remain in the Shift-DR TAPC state until all responses have been exported and all new stimuli have been imported- (in blue) all components on the UUT (series topology) pass through the Update-DR TAPC state wherein new stimuli are applied in concert- (in grey) all components on the UUT (series topology) dwell in/ pass through the Run-Test/Idle TAPC state wherein transient stimuli may be generated in concert The divergence introduced by the 1149.7 star topology is that, due to shared wiring of TDIC and TDOC for star-4 or TMSC for star-2, only one component may be operated in the Shift-DR TAPC state at a time.Fortunately, we can take from the above discussion that the Shift-DR TAPC state is actually neutral to the requirements of the test application. Thus, the needs of the test application can be served, even for a star topology if each of the TAPC states Capture-DR, Update-DR, and Run-Test/Idle can be operated in concert across all of the UUT components of interest.It is for just this purpose that the scan selection directives (SSD) were devised. Figure 13 illustrates the scan-state sequence made possible by the SSDs (star topology).Run-Test-Idle1Select-DR-ScanCapture-DRExit1-DRExit2-DRUpdate-DRShift-DRPause-DR11111Figure 13—Scan-state sequence for test applications,modified for star topology。
854285-001 1 Memory Module Replacement Instruction
Memory Module Replacement InstructionsBefore you beginObserve the following requirements before removing and replacing memory.WARNING : Never open the cover while the power cord is attached. You might damage your computer or be injured by the spinning fan blades.WARNING : Avoid touching sharp edges inside the computer.CAUTION : Static electricity can damage the electroniccomponents inside the computer. Discharge static electricity by touching the metal cage of the computer before touching any internal parts or electronic components. Tools neededPhillips #2 screwdriver Hex toolSmall screws are easily lost. Remove screws over a surface that enables you to retrieve them if they fall.TroubleshootingIf the computer displays a memory error after you have turned it back on, turn the computer off and unplug the power cord. Open up the memory compartment and make sure the memory module is inserted all the way into the slot, and then press down on it to be sure it is firmly seated.Memory compatibilityThe computer uses SODIMMs (small outline dual in-line memory modules) that must meet the following requirements: ● 204-pin ● DDR4-2133● Unbuffered, non-ECC (64-bit)● 1.2 V● 16 GB maximum installable memoryBecause the memory uses dual channels, you must use the same memory module type for both sockets.NOTE : The actual memory transfer speed might vary, based on the processor used in your computer.NOTE : Memory performance might vary due to different system configurations.Removing the memory module1. Disconnect the power cord and all attached cables from the back of the computer.854285-0012. Using caution, lay the computer down on a flat surface covered with a soft cloth.3. To remove the stand, rotate it upward(1), remove the four hex screws (2), and then lift the stand up and off the computer (3).4. To remove the rear cover, remove the two screw covers (1) and two Phillips screws (2) located in the bottom of the cover. Lift off the cover, and then place it upside down next to the computer(3). The optical drive ismounted on the inside of the rear cover, and a cableconnects it to the system board.5. Locate the memory modules: 1. Hard drive 2.Memory modules6. Remove the five Phillips screws that secure the system board cover (1), and then lift the cover off the computer (2).7. Spread the two retention clips outward (1) until the memory module tilts up at a 45-degree angle. Remove the module (2). Use the same procedure to remove both memory modules.8. Touch the replacement memory module bag to the metal of the computer, and then remove the replacement memory module from the bag.Replacing the memory module1. Align the notched edge of the module with the tab in the slot, and then press the module into the slot at an angle until it is seated (1). Press down on the module until the side retention clips snap into place (2).NOTE : Memorymodules are notched to prevent incorrect insertion.2. Position the system board cover over the system board (1), and then replace the five Phillips screws (2).3. Align the rear cover with the computer and press itdown until it snaps into place (1). Replace the two Phillips screws (2), and then replace the screw covers(3).4. Position the top of the stand on the computer (1), and then replace the four hex screws (2). Rotate the stand downward (3).5. Plug the power cord and any additional cables into the back of the computer.6. Press the power button to turn on the computer.© Copyright 2016 HP Development Company, L.P.The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying suchproducts and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.First Edition: May 2016PRINTER: Replace this bo x with Pr inted- In (PI)Statement(s) as per spec.NOTE: This box is simply a placeho lder. PI Statement(s) do n ot have to fit inside the box but sh ould be placed in this area.。
Interface Probe with Float Installation and Operat
Interface Probe with Float Installation and Operation ManualTable of ContentsSection 1: System Description (4)Section 2: System Installation (6)Section 3: System Operation (8)Section 4: System Maintenance (10)Section 5: System Troubleshooting (10)Section 6: System Specifications (12)Section 7: System Schematic (13)Section 8: Replacement Parts List (14)The Warranty (17)DOCUMENTATION CONVENTIONS This uses the following conventions to present information:An exclamation point icon indicates a WARNING of a situationor condition that could lead to personal injury or death. Youshould not proceed until you read and thoroughly understand theWARNING message.WARNINGCAUTIONA raised hand icon indicates CAUTION information that relates toa situation or condition that could lead to equipment malfunctionor damage. You should not proceed until you read and thoroughlyunderstand the CAUTION message.A note icon indicates NOTE information. Notes provide additionalor supplementary information about an activity or concept.NOTENotice for consumers in Europe:This symbol indicates that this product is to be collectedseparately.The following applies only to users in European countries:∙This product is designated for separate collection at an appropriate collection point. Do not dispose of as household waste.∙For more information, contact the seller or the local authorities in charge of waste management.Section 1: System DescriptionFunction and TheoryThe Geotech Interface Probe (GIP) with Float is a portable instrument used to accurately measure water and hydrocarbon layer thickness in monitoring wells. The unit consists of a stainless steel and PTFE probe attached to a reel-mounted, HDPE coated engineer’s tape. The engineer's tape comes in standard or metric graduations, and is accurate to1/100th of a foot per 100’ (3mm/ 30.5m). The probe also contains a float that detects hydrocarbon levels and a pair of stainless steel contacts for sensing conductive fluids.The Interface Probe reel has an audible signal and a visible red LED that are activated when the probe reaches water or product. The unit features an auto shutoff circuit to prevent battery discharge. This auto shutoff circuit allows the instrument 10 minutes of continuous operation before the unit shuts off.When the probe is lowered down a well and contacts any fluid with a specific gravity of .60 or greater, the stainless steel contacts and float will activate the visible and audible signals. If the fluid is non-conductive, the LED will be red and a solid tone will sound. If the fluid is water or other conductive fluid, the conductive contacts will cause the LED to turn green and the tone will oscillate. If the probe is lowered through the water layer to a non-conductive layer (such as DNAPL) the tone will go solid again and the LED will return to red.The Geotech Interface Probe with Float is intended for use as a depth to water or product measuring device. Using the Interface Probe for any other purpose may compromise safety of the operator and/or voi d manufacturer’s warranty.To avoid damage to the tape and strain relief, do not over tightenthe reel with probe when placed in storage.System ComponentsTape LeaderGuardFigure 1-1: System ComponentsMeasuring TapeThe specially coated measuring tape connects the probe with the reel assembly and provides an accurate means of measuring the distance from the wellhead or tank port to the air/water, air/oil, or oil/water interface. The tape contains all the wires running between the probe and the circuitry in the housing assembly. Engineering tape assemblies are in decimal feet and Metric tape assemblies are in meters (down to millimeters).Section 2: System InstallationThe reel frame has a metal loop called the “hanger”. The hanger can be used to hang the reel frame onto the well casing (as shown in Figure 2-1). The tape can then slide easily over the side of the reel leg.Figure 2-1: Reel frame on well casing.If you are not able to hang the frame onto the wellhead, then either use the white plastic leader guard (standard with all units), or the optional Tape Guide, to prevent the edge of the wellhead from damaging the tape. Figure 2-2 is an example of the two parts.Figure 2-2: Tape Guide (optional), Tape Leader GuardDo not use the tape leader guard in wells larger than 4” (10cm), as it may fall down the well.Section 3: System OperationVerify Operation of the ProbeTest the battery by pressing the "ON/TEST" button. If the buzzer makes a loud signal and the LED is visible, the battery is adequate for normal operation. Pressing the "ON/TEST" button provides 10 minutes of operation.Test the instrument operation. Remove the probe from the retaining clip and raise the phenolic float. When the float switch triggers, the visible signal will be red and the audible signal will emit a steady tone. With the float still raised, moisten your fingers and touch the float shaft and the conductive contact. If the battery is properly charged, the visible signal will turn green and the tone will oscillate. Successful completion of these tests will indicate that the unit is operating properly.Measuring Fluid LevelsLower the probe down the well until the signals activate and then read the measurement at the top of the well casing or other reference point. Record this figure as the first fluid level.Continue to lower the probe until the signals change. Record the measurement at the reference point as the second fluid level.To determine the product layer thickness, subtract the first reading from the second reading.Measuring Water Levels in Product-Free WellsIf the probe immediately emits a green light, nonconductive fluids are absent from the surface of the water.To avoid damage to the tape and strain relief, do not over tightenthe reel with probe when placed in storage.StorageIf the GIP with float is not used and is stored for longer than three (3) months, remove the battery to prevent battery leakage, which can cause internal damage.Geotech Interface Probe with Float Correction Factors2nd Reading ____’/m + .08’ (.024 m) = ____’/m(total depth)MINUS —1st Reading ____’/m - .08’ (.024 m) = ____’/m(to product layer)CORRECTED PRODUCT THICKNESS = ____’/mExample:You find that a sinker (DNAPL) begins at 22.36’ / 6.82 m (1st reading) and the total depth of your well is 23.61’ / 7.20 m (2nd reading). Use the above formula to get your correct product thickness.2nd Reading 23.61’ + .08’= 23.69’(total depth) (7.20 m + .024 m) = (7.22 m)MINUS —1st Reading 22.36’ - .08’= 22.28’(to product layer) (6.82 m - .024 m) = (6.79 m)CORRECTED PRODUCT THICKNESS = 1.41’ (.429 m)Product thickness can be determined by adding .15’ (.045 m) to the difference of your original measurements.Section 4: System MaintenanceBattery ReplacementReplace the battery when the audible and visible signals become weak or the unit does not operate.1. Gently remove the battery tray.2. Remove the old battery and replace it with a new one.Be aware of the polarity (+, -) of the battery when placing the newbattery in the tray. Use a 9V alkaline battery only.CleaningThe Geotech Interface Probe with Float can be cleaned with mild detergents such as trisodium phosphate (TSP), or phosphate free type cleaner. If other detergents are used, take care to select detergents that are compatible with PTFE, polypropylene, and stainless steel. The reel should not be submerged in any liquid, but may be cleaned with a damp cloth.If the float becomes covered with silt or mud, remove the float retaining clip, slide the float off the shaft, and clean both the float and the float shaft. Replace the float so the arrow is facing the top of the probe and replace the retaining clip.The conductive contact can be cleaned with detergent and a small brush.The float shaft at the bottom of the probe is not designed to beremoved.Field calibration of the probe is not normally required.Section 5: System TroubleshootingProblem: No signal (audible or visible) when unit is turned on.Solutions:∙The battery is discharged. Check or change battery (Section 4: System Maintenance).∙The circuit is malfunctioning. Contact Geotech Service.Problem: No indication of product.Solutions:∙The float is stuck. Clean the float and travel path (Section 4: System Maintenance).∙Water is bridging at the bottom of the probe. Clean the probe. Do not unscrew the float switch.∙The circuit is malfunctioning. Contact Geotech Service.Problem: No indication of water.Solutions:∙The conductive contact is dirty. Clean the contact (Section 4).∙There is an open connection in the tape. Replace tape and/or probe.∙The circuit is malfunctioning. Contact Geotech Service.Problem: The signal (audible or visible) is intermittent.Solutions:∙There is an open connection in the tape. Replace tape and/or probe.∙There is a loose connection in the circuit or the probe. Repair the connection.∙The float is damaged or missing. Replace the float.Problem: The signal (audible or visible) is continuous when not in water.Solutions:∙Make sure the meter is in standard mode. Place the mode switch to the “Right“, for normal operation.∙The conductive contact is dirty (causing bridging). Clean the contact (Section 4).∙There is a short in the tape and/or probe. Replace tape and/or probe.∙The circuit is malfunctioning. Contact Geotech Service.For technical assistance, call Geotech Environmental Equipment at 1-303-320-4764 or 1-800-833-7958Section 6: System SpecificationsLength/Weight: 100 foot (30 meters) = 9 lbs (4 kg)200 foot (60 meters) = 11 lbs (5 kg)300 foot (100 meters) = 14 lbs (6.5 kg) ProbeMaterial: Stainless steel, PTFE, Viton Weight: 19.75 oz (560 g)Diameter: 1.5” (3.8 cm)Length: 8.9” (22.6 cm)Minimum ConductivityThreshold (detects water at): > 6.7µSMinimum DetectableHydrocarbon .01 footTapeTape: HDPE coated steel-core tape.Accuracy: 1/100 of a foot per 100’ (3mm /30.5m)Per Federal Specification: GGG-T-106EResolution: Imperial units 1/100 per foot metric units 1 mmReel/FrameMaterial: Polypropylene & aluminumSize: 13” H x 11” W x 7” D (33 cm H x 28 cm W x 18 cm D) UnitBattery: 9 volt alkalineSelf shut-off time: 10 minutesOutput tone: 500 HzModulation (water detected): 3.5 HzOperating temperature range: 32 – 140 °F (0 – 60 °C)Storage temperature range: -40 – 158 °F (-40 – 70 °C)Response time: <10 millisecondsSection 7: System SchematicFigure 7-1: Geotech Interface Probe with Float (front and side view)Section 8: Replacement Parts ListFigure 8-1: Frame, Reel & Control Assembly Parts ListItem # Parts Description Part #1 ASSY,FRAME,KIR 520500272 ASSY,REEL,100FT,GEOWLM 52050029ASSY,REEL,200FT,GEOWLM 52050030ASSY,REEL,300FT,GEOWLM 52050031 3ASSY,CONTROL,KIR IP TAPE LENGTH REQUIRED 52050036 3a RING, RETAINING, SS, SPIRAL WLM/KIR (FACEPLATE) 12050022 4KNOB,KNURLED,3/4X5/16",BLK (USE WITH #12050525)12050524 5PROBE HOLDER,KIR520502856 SCREW,SS8,1/4-20X1.375",SHCS 120505257NUT,NYL,1/4-20,HEX175001298 KNOB,PHENOLIC,OVAL/TAPERED,REEL HANDLE 120500029 BOLT,SS8,KNOB HANDLE,5/16X1.5",1/4-20THRD 1750012310 HANDLE GRIP,VINYL,3/4X5-1/16",BLACK 12050007 Not Shown:GUARD,LEADER,PROPAMIDE,NATURAL 12050060GUIDE,TAPE,DELRIN 22050255CASE,WLM/IP,100-300' 12050059MANUAL,INSTRUCTION,IP W/FLOAT 12050096Figure 8-2: Tape/Probe Parts ListItem # Parts Description Part #1 ASSY,TAPE,KIR IP,30M HDPE TAPE 52050040ASSY,TAPE,KIR IP,60M HDPE TAPE 52050041ASSY,TAPE,KIR IP,100M HDPE TAPE 52050011ASSY,TAPE,KIR IP,100FT HDPE TAPE 52050032ASSY,TAPE,KIR IP,200FT HDPE TAPE 52050033ASSY,TAPE,KIR IP,300FT HDPE TAPE 520500342 O-RING,VITON,#215,BROWN 120500283 ASSY,PROBE,KIR IP,1.5",W/FLOAT 520500284 KIT,FLOAT,KIR IP,(2 PK) INCLUDES 2 "E" CLIPS 52050038The WarrantyFor a period of one (1) year from date of first sale, product is warranted to be free from defects in materials and workmanship. Geotech agrees to repair or replace, at Geotech’s option, the portion proving defective, or at our option to refund the purchase price thereof. Geotech will have no warranty obligation if the product is subjected to abnormal operating conditions, accident, abuse, misuse, unauthorized modification, alteration, repair, or replacement of wear parts. User assumes all other risk, if any, including the risk of injury, loss, or damage, direct or consequential, arising out of the use, misuse, or inability to use this product. User agrees to use, maintain and install product in accordance with recommendations and instructions. User is responsible for transportation charges connected to the repair or replacement of product under this warranty.Equipment Return PolicyA Return Material Authorization number (RMA #) is required prior to return of any equipment to our facilities, please call our 800 number for appropriate location. An RMA # will be issued upon receipt of your request to return equipment, which should include reasons for the return. Your return shipment to us must have this RMA # clearly marked on the outside of the package. Proof of date of purchase is required for processing of all warranty requests.This policy applies to both equipment sales and repair orders.FOR A RETURN MATERIAL AUTHORIZATION, PLEASE CALL OURSERVICE DEPARTMENT AT 1-800-833-7958.Model Number: ________________Serial Number: ________________Date of Purchase: ________________Equipment DecontaminationPrior to return, all equipment must be thoroughly cleaned and decontaminated. Please make note on RMA form, the use of equipment, contaminants equipment was exposed to, and decontamination solutions/methods used. Geotech reserves the right to refuse any equipment not properly decontaminated. Geotech may also choose to decontaminate the equipment for a fee, which will be applied to the repair order invoice.Geotech Environmental Equipment, Inc. 2650 East 40th Avenue Denver, Colorado 80205。
接口控制和数据标准技术英文
接口控制和数据标准技术英文
接口控制和数据标准技术的英文术语分别是"Interface Control"和"Data Standardization Technology"。
Interface Control是指在系统或组件之间进行数据交换和通信时所采用的控制方法和规范。
这包括了接口的定义、协议、数据格式等方面的规范和标准。
Data Standardization Technology则是指对数据进行标准化处理的技术，包括数据格式、数据结构、数据元素的定义和标准化等方面的技术和方法。
这些术语在信息技术和工程领域经常被用到，对于确保系统和组件之间的互操作性和数据一致性具有重要意义。
一次插件标准
一次插件标准The issue of a universal plugin standard has been a topic of discussion in the technology industry for quite some time. Many consumers and businesses are frustrated by the lack of compatibility between different devices and the constant need for separate chargers and cables. This not only creates inconvenience but also contributes to electronic waste as outdated chargers are discarded when new devices are purchased.一直以来，一次插件标准的问题在科技行业中一直是一个讨论的话题。
许多消费者和企业对不同设备之间缺乏兼容性和需要单独充电器和电缆的不断需求感到沮丧。
这不仅带来了不便，还导致了电子废物的产生，因为过时的充电器在购买新设备时被丢弃。
The European Commission has recognized the need for a common charger standard and has been pushing for a unified approach to charging cables. This initiative aims to reduce electronic waste, simplify the charging process, and improve the user experience. By having a single universal standard, consumers would no longer needto carry multiple chargers when traveling or switch out cables when using different devices.欧洲委员会认识到了共同充电器标准的需要，并一直在推动充电线的统一标准。
G.823-以2048kbs系列等级为基础的数字网内抖动和漂动的控制
INTERNATIONAL TELECOMMUNICATION UNIONG.823(03/2000) TELECOMMUNICATIONSTANDARDIZATION SECTOROF ITUSERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKSDigital networks – Quality and availability targetsThe control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchyITU-T Recommendation G.823(Formerly CCITT Recommendation)ITU-T G-SERIES RECOMMENDATIONSTRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199G.200–G.299 GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMSINDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONEG.300–G.399 SYSTEMS ON METALLIC LINESG.400–G.449 GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONESYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITHMETALLIC LINESCOORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499 DIGITAL NETWORKS G.800–G.899 General aspects G.800–G.809 Design objectives for digital networks G.810–G.819 Quality and availability targets G.820–G.829 Network capabilities and functions G.830–G.839 SDH network characteristics G.840–G.849 Management of transport network G.850–G.859 SDH radio and satellite systems integration G.860–G.869 Optical transport networks G.870–G.879 DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999For further details, please refer to the list of ITU-T Recommendations.ITU-T Recommendation G.823The control of jitter and wander within digital networkswhich are based on the 2048 kbit/s hierarchySummaryThis ITU-T Recommendation specifies the maximum network limits of jitter and wander that shall not be exceeded and the minimum equipment tolerance to jitter and wander that shall be provided at any relevant transport or synchronization interfaces which are based on the 2048 kbit/s hierarchy. The requirements for the jitter and wander characteristics that are specified in this ITU-T Recommendation must be adhered to in order to ensure interoperability of equipment produced by different manufacturers and a satisfactory network performance.SourceITU-T Recommendation G.823 was revised by ITU-T Study Group 13 (1997-2000) and approved under the WTSC Resolution 1 procedure on 10 March 2000.KeywordsClocks, Input Jitter Tolerance, Input Wander Tolerance, Network Limits, Output Jitter, Output Wander, Synchronization, Timing.ITU-T G.823 (03/2000) iFOREWORDThe International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.The approval of ITU-T Recommendations is covered by the procedure laid down in WTSC Resolution 1.In some areas of information technology which fall within ITU-T’s purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.NOTEIn this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database.ã ITU 2001All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. ii ITU-T G.823 (03/2000)CONTENTSPage1 Scope (1)2 References (2)3 Definitions (2)4 Abbreviations (3)5 Network limits for traffic interfaces (4)5.1 Network limits for output jitter at traffic interfaces (4)5.2 Network limits for output wander at traffic interfaces (5)5.2.1 2048 kbit/s interface output wander limit (6)5.2.2 34 368 kbit/s interface output wander limit (7)5.2.3 139 264 kbit/s interface output wander limit (8)6 Network limits for synchronization interfaces (8)6.1 Network limits for output jitter at synchronization interfaces (9)6.2 Network limits for output wander at synchronization interfaces (9)6.2.1 PRC interface output wander limit (10)6.2.2 SSU interface output wander limit (11)6.2.3 SEC interface output wander limit (13)6.2.4 PDH synchronization interface output wander limit (14)7 Jitter and wander tolerance of network interfaces (16)7.1 Jitter and wander tolerance of traffic interfaces (16)7.1.1 64 kbit/s input jitter and wander tolerance (17)7.1.2 2048 kbit/s input jitter and wander tolerance (18)7.1.3 8448 kbit/s input jitter and wander tolerance (19)7.1.4 34 368 kbit/s input jitter and wander tolerance (20)7.1.5 139 264 kbit/s input jitter and wander tolerance (21)7.2 Jitter and wander tolerance of synchronization interfaces (22)Annex A − Network model underlying the synchronization network limit (22)A.1 Introduction (22)A.2 Considerations on the network model (22)A.3 Information regarding the simulations (25)Annex B − Network wander reference model and parameters (26)B.1 Wander reference model for traffic interfaces (26)B.1.1 Asynchronous PDH connection (26)B.1.2 Synchronous PDH connection (27)B.1.3 Specification of wander by MRTIE parameter (27)ITU-T G.823 (03/2000) iiiPage B.2 Wander reference model for synchronization interfaces (28)B.2.1 Specification of wander by MTIE and TDEV parameters (30)Appendix I − Wander limit considerations for SDH transport networks (30)I.1 Introduction (30)I.1.1 Wander reference model for SDH (30)I.1.2 Sources of wander (31)I.1.3 Wander accumulation limiting effects (32)I.1.4 Network configuration and performance (32)I.1.5 Correlation of wander sources (32)I.1.6 Network conditions for the output wander limits (32)I.2 Derivation of wander specification limits (33)I.2.1 Wander specification limits (34)Appendix II − Measurement methodologies for output wander (34)interfaces (34)II.1 SynchronizationII.1.1 Synchronous signals (34)interfaces (35)II.2 TrafficII.2.1 Synchronous signals (PDH bit-rates) (35)II.2.2 Asynchronous signals (PDH bit-rates) (36)Appendix III − Measurement guidelines for input jitter and wander tolerance of equipment interfaces (38)iv ITU-T G.823 (03/2000)Introduction and backgroundIn a digital network, jitter and wander accumulate on transmission paths according to the jitter and wander generation and transfer characteristics of each equipment interconnected. This equipment may be different types of multiplexers/demultiplexers, cross-connects, clocks and line systems, for example.An excessive amount of jitter and wander can adversely affect both digital (e.g. by generation of bit errors, slips and other abnormalities) and analogue signals (e.g. by unwanted phase modulation of the transmitted signal). The consequences of such impairment will, in general, depend on the particular service that is being carried and the terminating or adaptation equipment involved.It is therefore necessary to set limits on the maximum magnitude of jitter and wander, and the corresponding minimum jitter and wander tolerance at network interfaces, in order to guarantee a proper quality of the transmitted signals and a proper design of the equipment. These network limits are independent of the particular service that is being carried.ITU-T G.823 (03/2000) vITU-T Recommendation G.823The control of jitter and wander within digital networkswhich are based on the 2048 kbit/s hierarchy1 ScopeThis ITU-T Recommendation specifies the relevant parameters and their limiting values that are able to satisfactorily control the amount of jitter and wander present at Network Node Interfaces (NNI) of Plesiochronous Digital Hierarchy (PDH) and synchronization networks which are based on the first-level hierarchical bit rate of 2048 kbit/s.This ITU-T Recommendation also specifies the jitter and wander requirements at PDH User-Network Interfaces (UNI). However, particular terminals or services may have additional jitter and wander requirements and in those cases the relevant ITU-T Recommendations shall apply. Requirements for NNI of PDH and synchronization networks which are based on the first-level hierarchical bit rate of 1544 kbit/s are specified in ITU-T Recommendation G.824 and requirements for Synchronous Digital Hierarchy (SDH) NNI are specified in ITU-T Recommendation G.825.The jitter and wander requirements specified in this ITU-T Recommendation are applicable to the interfaces irrespective of the underlying transport mechanism (PDH, SDH or ATM networks, for example).The jitter and wander requirements for an interface will be different, depending on whether the signal at the interface is used to transport traffic and/or synchronization. The requirements for both traffic and synchronization interfaces are specified in this ITU-T Recommendation in the appropriate clauses.A synchronization network that conforms to the network limits for jitter and wander specified in this ITU-T Recommendation will be suitable for the synchronization of SDH and Public Switched Telephone Network (PSTN) networks.This ITU-T Recommendation also specifies the jitter and wander requirements for interfaces using the generic frame structures at PDH rates as defined in ITU-T Recommendation G.832.The electrical characteristics of the relevant PDH network interfaces are defined in ITU-T Recommendation G.703.The jitter and wander control philosophy of this ITU-T Recommendation is based on the need:a) to specify a maximum network limit of jitter and wander that shall not be exceeded at anyrelevant interface;b) to specify a minimum equipment tolerance to jitter and wander that shall be provided at anyrelevant interface;c) to establish a consistent framework for the specification of individual digital equipmenttypes; andd) to provide sufficient information and guidelines for organizations to measure and study jitterand wander characteristics in any network configuration.ITU-T G.823 (03/2000) 12 ReferencesThe following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.– ITU-T Recommendation G.703 (1998), Physical/electrical characteristics of hierarchical digital interfaces.– ITU-T Recommendation G.707 (1996), Network node interface for the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.783 (1997), Characteristics of Synchronous Digital Hierarchy (SDH) equipment functional blocks.– ITU-T Recommendation G.803 (2000), Architecture of transport networks based on the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.810 (1996), Definitions and terminology for synchronization networks.– ITU-T Recommendation G.811 (1997), Timing characteristics of primary reference clocks. – ITU-T Recommendation G.812 (1998), Timing requirements of slave clocks suitable for use as node clocks in synchronization networks.– ITU-T Recommendation G.813 (1996), Timing characteristics of SDH equipment slave clocks (SEC).– CCITT Recommendation G.822 (1988), Controlled slip rate objectives on an international digital connection.– ITU-T Recommendation G.824 (2000), The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy.– ITU-T Recommendation G.825 (2000), The control of jitter and wander within digital networks which are based on the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.832 (1998), Transport of SDH elements on PDH networks – Frame and multiplexing structures.– ITU-T Recommendation O.150 (1996), General requirements for instrumentation for performance measurements on digital transmission equipment.– ITU-T Recommendation O.171 (1997), Timing jitter and wander measuring equipment for digital systems which are based on the Plesiochronous Digital Hierarchy (PDH).– ITU-T Recommendation O.172 (1999), Jitter and wander measuring equipment for digital systems which are based on the Synchronous Digital Hierarchy (SDH).3 DefinitionsThis ITU-T Recommendation defines the following terms. Additional definitions relating to synchronization networks are provided in ITU-T Recommendation G.810, whilst the architectural principles of synchronization networks are described in ITU-T Recommendation G.803. Information regarding the wander reference models used in this ITU-T Recommendation is provided in Annexes A and B.2ITU-T G.823 (03/2000)interface: These interfaces provide an output signal with frequency that is 3.1 synchronousnormally traceable to a PRC.interface: These interfaces provide an output signal with frequency that is 3.2 asynchronousnot traceable to a PRC and that meets the frequency offset requirements given in ITU-T Recommendation G.703.interface: These interfaces may be asynchronous or synchronous and network jitter 3.3 trafficand wander limits are specified using the Maximum Relative Time Interval Error (MRTIE) parameter in this ITU-T Recommendation. Input jitter and wander tolerance is also specified in this ITU-T Recommendation. This interface category can be further sub-divided as follows:a) Interface is not able to provide synchronization, and is not required to. An example is aninterface supporting only 34 368 or 139 264 kbit/s PDH signals according to ITU-T Recommendation G.703.b) Interface is not able to provide synchronization at the defined performance level, butnevertheless is used to provide timing to other network elements such as terminal equipment, remote concentrators, etc. Examples include 2048, 34 368 and 139 264 kbit/s PDH signals transported on SDH, which may be subject to pointer justifications. ITU-T Recommendation G.803 recommends that these interfaces are not to be used for synchronization.c) Interface is able to provide synchronization at the defined performance level, in which caseit is defined to be a synchronization interface. An example is a synchronization interface operating at 2048 kbit/s. This sub-category may also include interfaces using the generic frame structures at PDH rates as defined in ITU-T Recommendation G.832.interface: These interfaces are synchronous and network wander limits are 3.4 synchronizationspecified using Maximum Time Interval Error (MTIE) and Time Deviation (TDEV) parameters with values given in this ITU-T Recommendation. The input jitter and wander tolerance of clock equipment ports is specified in other Recommendations (refer to 7.2).4 AbbreviationsThis ITU-T Recommendation uses the following abbreviations. Additional abbreviations relating to synchronization networks are provided in ITU-T Recommendation G.810.ATM Asynchronous Transfer ModeAU-n Administrative Unit, level nCLK ClockCMI Coded Mark InversionITU-T International Telecommunication Union – Telecommunication Standardization SectorFilterLPF Low-PassMRTIE Maximum Relative Time Interval ErrorMS-AIS Multiplex Section Alarm Indication SignalMTIE Maximum Time Interval ErrorElementNE NetworkNNI Network Node InterfacePDH Plesiochronous Digital Hierarchypk-pk peak-to-peakPLL Phase Locked Loopppm parts per millionPRBS Pseudo-Random Binary SequencePRC Primary Reference ClockPSTN Public Switched Telephone NetworkRMS Root Mean SquareRTIE Relative Time Interval ErrorSDH Synchronous Digital HierarchySEC SDH Equipment ClockSSU Synchronization Supply UnitSTM-N Synchronous Transport Module, level NTDEV Time DeviationTIE Time Interval ErrorTU-m Tributary Unit, level mIntervalUI UnitUIpp Unit Interval, peak-to-peakInterfaceUNI User-NetworkUTC Universal Time CoordinatedVC-n Virtual Container, level n5 Network limits for traffic interfaces5.1 Network limits for output jitter at traffic interfacesThe limits given in this clause represent the maximum permissible levels of jitter at interfaces within a digital network. Jitter as measured over a 60 second interval shall not exceed the limits specified in Table 1, when using the specified measurement filters.There is a close relationship between network limits and input tolerance such that the jitter measurement filter cut-off frequencies used in this clause have the same values as the jitter tolerance mask corner frequencies used in 7.1. Appendix I/G.825 has further information regarding this relationship.The limits given in Table 1 shall be met for all operating conditions and regardless of the amount of equipment preceding the interface. In general, these network limits are compatible with the minimum tolerance to jitter that all equipment input ports are required to provide.The functional description for measuring output jitter at a digital interface is provided in ITU-T Recommendation O.172.The high-pass measurement filters of Table 1 have a first-order characteristic and a roll-off of 20 dB/decade. The low-pass measurement filters have a maximally-flat, Butterworth characteristic and a roll-off of –60 dB/decade. Further specifications for the frequency response of the jitter measurement function such as measurement filter accuracy and additional allowed filter poles are given in ITU-T Recommendation O.172.Instrumentation in accordance with ITU-T Recommendations O.172 and O.171 is appropriate for measurement of jitter in SDH and PDH systems, respectively.NOTE − ITU-T Recommendation O.172 includes test set specifications for the measurement of SDH tributaries operating at PDH bit rates, where the test set requirements are more stringent than those relating only to PDH systems. Therefore, instrumentation in accordance with ITU-T Recommendation O.172 shall be used at PDH interfaces in SDH systems.Table 1/G.823 − Maximum permissible jitter at traffic interfacesInterfaceMeasurementbandwidth,–3 dB frequencies (Hz)Peak-to-peak amplitude(UIpp) (Note 3)64 kbit/s 20 to 20 k 0.25(Note 1) 3 k to 20 k 0.052048 kbit/s 20 to 100 k 1.518 k to 100 k (Note 2) 0.28448 kbit/s 20 to 400 k 1.53 k to 400 k (Note 2) 0.234 368 kbit/s 100 to 800 k 1.510 k to 800 k 0.15139 264 kbit/s 200 to 3.5 M 1.510 k to 3.5 M 0.075NOTE 1 − For the codirectional interface only.NOTE 2 − For 2048 kbit/s and 8448 kbit/s interfaces within the network ofan operator, the high-pass cut-off frequency may be specified to be 700 Hz(instead of 18 kHz) and 80 kHz (instead of 3 kHz) respectively. However, atinterfaces between different operator networks, the values in the table apply,unless involved parties agree otherwise.NOTE 3 –64 kbit/s 1 UI = 15.6 µs2048 kbit/s 1 UI = 488 ns8448 kbit/s 1 UI = 118 ns34 368 kbit/s 1 UI = 29.1 ns139 264 kbit/s 1 UI = 7.18 ns5.2 Network limits for output wander at traffic interfacesThe MRTIE specifications given in this subclause are intended for application to both asynchronous and synchronous PDH interfaces. Refer to Figures B.1 and B.2, respectively, for the reference network configurations. In the case of asynchronous interfaces, a frequency offset within the limits specified in ITU-T Recommendation G.703 is permitted, in addition to the wander specified in the following subclauses.It is required that, within a synchronized network, digital equipment provided at nodes shall accommodate permitted phase deviations on the incoming signal, i.e. under normal synchronized conditions, impairments will not occur.However, it should be recognized that, as a result of some performance degradations, failure conditions, maintenance actions and other events, the phase difference between the incoming signal and the internal timing signal of the terminating equipment may exceed the jitter and wander tolerance of the equipment which may result in an abnormal event such as a slip or bit-error burst.In addition, at a node which connects to an independently-synchronized network (or where plesiochronous operation is used in national networks), the phase difference between the incoming signal and the internal timing signal of the terminating equipment may eventually exceed the wander tolerance of the equipment in which case an abnormal event such as a slip may occur. The maximum permissible long-term mean controlled slip rate resulting from this mechanism is derived from the clock performance defined in ITU-T Recommendation G.811, i.e. no more than one slip in 70 days. NOTE − The wander specifications defined in the following subclauses are consistent with the derivation of network limits described for the case of SDH network transport in Appendix I.The wander measurement requirements (e.g. sampling time and measurement interval) for MTIE, MRTIE and TDEV parameters, the 10 Hz wander measurement filter characteristic and the functional description for measuring output wander are described in ITU-T Recommendation O.172. Instrumentation in accordance with ITU-T Recommendation O.172 is appropriate for measurement of wander parameters.Measurement methodologies used to measure the MRTIE parameter are described in Appendix II. 5.2.1 2048 kbit/s interface output wander limitThe maximum level of wander that may exist at a 2048 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 2. The resultant overall specification is illustrated in Figure 1.Table 2/G.823 − 2048 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 <τ≤ 0.2 46 τ0.2 <τ≤ 32 932 <τ≤ 64 0.28 τ64 <τ≤ 1 000 (Note) 18NOTE − For the asynchronous configuration (refer toFigure B.1), the maximum observation interval to be considered is 80 seconds.T1315370-99Observation Interval τ (sec)MRTIE (µsec)1001892.310.111010010000.050.2326410000.01Figure 1/G.823 − 2048 kbit/s interface output wander limit5.2.2 34 368 kbit/s interface output wander limitThe maximum level of wander that may exist at a 34 368 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 3. The resultant overall specification is illustrated in Figure 2.NOTE − 34 368 kbit/s signals can be framed in accordance with ITU-T Recommendation G.832.Table 3/G.823 − 34 368 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 < τ ≤ 0.073 14 τ 0.073 < τ ≤ 2.5 1 2.5 < τ ≤ 10 0.4 τ 10 < τ ≤ 804T1315380-99Observation Interval τ (sec)MRTIE (µsec)0.70.11101000.050.073 2.510800.0114Figure 2/G.823 − 34 368 kbit/s interface output wander limit5.2.3 139 264 kbit/s interface output wander limitThe maximum level of wander that may exist at a 139 264 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 4. The resultant overall specification is illustrated in Figure 3.NOTE − 139 264 kbit/s signals can be framed in accordance with ITU-T Recommendation G.832.Table 4/G.823 − 139 264 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 < τ ≤ 0.15 6.8 τ 0.15 < τ ≤ 2.5 1 2.5 < τ ≤ 10 0.4 τ 10 < τ ≤ 804T1315390-99Observation Interval τ (sec)MRTIE (µsec)1010.340.10.11101000.050.15 2.510800.0114Figure 3/G.823 − 139 264 kbit/s interface output wander limit6 Network limits for synchronization interfacesThe specification of network limits for synchronization interfaces is primarily intended to reflect the results of a theoretical analysis of the worst-case accumulation of jitter and wander in a synchronization network. These values then serve to specify tolerance requirements for synchronization equipment.It should, however, also be possible to verify through measurements in a real network that the jitter and wander at a particular interface does not exceed the specified limits. The location of the interface in the synchronization chain of that network determines what margin may be expected with reference to the network limits.As shown in Figure B.3, an SSU may receive its timing via SDH or PDH distribution. The network limit at the output of these distribution chains represents the amount of jitter and wander that an SSU may experience at its input. Since there is more jitter allowed at PDH interfaces than at SDH Synchronous Transport Module, level N (STM-N) interfaces, the network limit for the PDH distribution outputs represents the worst-case that the SSU should tolerate at its input.The jitter and wander tolerance of an SEC should be (at least) the amount of jitter and wander at the input of the last SEC of a synchronization chain. Since the contribution of the last SEC in the chain to the network limit at SEC outputs (that is the amount of jitter and wander that may be expected at the output of the last SEC of the chain) is small, the network limit at the SEC output interface can be used as the jitter and wander tolerance requirement for an SEC.6.1 Network limits for output jitter at synchronization interfacesThe maximum allowable high frequency noise components of a timing signal are specified by the network limits for jitter given in Table 5. These network limits are compatible with the minimum tolerance to jitter that clock equipment input ports are required to provide. The limits given in Table 5 shall be met for all operating conditions at 2048 kbit/s and 2048 kHz synchronization interfaces.Jitter as measured over a 60 second interval shall not exceed the specified limits, when using the specified measurement filters.The functional description for measuring output jitter at a digital interface is provided in ITU-T Recommendation O.172. Further requirements concerning the measurement of jitter are defined in 5.1.Table 5/G.823 − Maximum permissible jitter at synchronization interfacesOutput InterfaceMeasurementbandwidth,–3 dB frequencies (Hz)Peak-to-peak amplitude(UIpp)PRC 20 to 100 k 0.05SSU 20 to 100 k 0.05SEC 20 to 100 k 0.549 to 100 k 0.2PDH synchronization 20 to 100 k 1.518 k to 100 k 0.2NOTE − For 2048 kbit/s and 2048 kHz synchronization interfaces, UIpp refers tothe reciprocal of the clock frequency.6.2 Network limits for output wander at synchronization interfacesAt very low frequencies, synchronization networks are transparent to wander. Consequently, two signals received in the same node that derive their timing from the same source, but over different paths, may in the worst-case have opposite phase deviation. The minimum wander tolerance in the frequency range where relevant equipment is affected by the differential phase variation between two inputs is therefore higher than the network limit for absolute wander. The performance of a clock is only influenced by the phase variation that is experienced at the selected synchronization input. That is why the absolute network limits in the following subclauses can be used directly to specify wander tolerance of the SSU and SEC.The network limit requirements for TDEV are derived from simulation, taking into account the 18 µs wander budget and the requirements of ITU-T Recommendation G.822 (further information is provided in Annex A). However, large diurnal wander with a period of one day and sinusoidal characteristic may cause the TDEV network limit (at SSU, SEC or PDH interfaces) to be exceeded, even if the corresponding MTIE requirement is met. This is because the TDEV parameter does not strongly filter sinusoidal components of wander.。
AVR教程 AVR Development Tools
Single step, run, etc. Unlimited number of breakpoints
• Supported by AVR Studio
7
JTAGICE mkII – New features
• debugWIRE interface
All configuration done from AVR Studio
• Unlimited Number of Breakpoints • Trace • Profiling • Source Level Debugging
▪ Footprint for second transceiver on PCB
All the electrical features necessary to seamlessly connect the AT90CAN128 to a CAN bus
• AT90CAN128’s CAN controller support BOSCH GmbH’s Controller Area Network (CAN) specification
• Front-end software integrated in AVR Studio • DOS command line front-end • Early support for new devices
5
STK500 Features
• Software selectable Voltage and Frequency • 6 and 10 pin ISP output for In-System Programming • Command-line interface for production programming • Expansion Headers for Plug-In modules and Prototyping Area • Additional RS-232 Port For General Use • Onboard Oscillator
HPMPI2.2
HPMPI2.2 For Lin...Example 1% export MPI_IC_ORDER="elan:TCP"% export MPIRUN_SYSTEM_OPTIONS="-subnet 192.168.1.1"% export MPIRUN_OPTIONS="-prot"% $MPI_ROOT/bin/mpirun -prun -n4 ./a.outThe command line for the above will appear to mpirun as $MPI_ROOT/bin/mpirun-subnet 192.168.1.1 -prot -prun -n4 ./a.out and the interconnect decision willlook for the presence of Elan and use it if found. Otherwise, TCP/IP will be used and the communication path will be on the same subnet as the 192.168.1.* host.Example 2 TCP/IP over GigEThe following is an example using TCP/IP over GigE, assuming GigE is installed and192.168.1.1 corresponds to the ethernet interface with GigE. Note the implicit use of-subnet 192.168.1.1 is required to effectively get TCP/IP over the proper subnet, if eth0 isnot the gigabit interface.% export MPI_IC_ORDER="elan:TCP"% export MPIRUN_SYSTEM_OPTIONS="-subnet 192.168.1.1"% $MPI_ROOT/bin/mpirun -prot -TCP -prun -n4 ./a.outExample 3 TCP/IP over Elan4The following is an example using TCP/IP over Elan4, assuming Elan4 is installed and configured. The subnet information is omitted, Elan4 is installed and configured, andTCP/IP via -TCP is explicitly requested.% export MPI_IC_ORDER="elan:TCP"% export MPIRUN_SYSTEM_OPTIONS=" "% $MPI_ROOT/bin/mpirun -prot -TCP -prun -n4 ./a.outExample 4 Protocol Maps• This runs on ELAN[user@opte10 user]$ bsub -I -n3 -ext "SLURM[nodes=3]" $MPI_ROOT/bin/mpirun -prot-srun ./a.out Job <59304> is submitted to default queue <normal>.<<Waiting for dispatch ...>><<Starting on lsfhost.localdomain>>Host 0 -- ELAN node 0 -- ranks 0Host 1 -- ELAN node 1 -- ranks 1Host 2 -- ELAN node 2 -- ranks 2host | 0 1 2======|================0 : SHM ELAN ELAN1 : ELAN SHM ELAN2 : ELAN ELAN SHMHello world! I'm 0 of 3 on opte6Hello world! I'm 1 of 3 on opte7Hello world! I'm 2 of 3 on opte8• This runs on TCP/IP over the GigE network configured as 172.20.x.x on eth0 [user@opte10 user]$ bsub -I -n3 -ext "SLURM[nodes=3]" $MPI_ROOT/bin/mpirun -prot-TCP -srun ./a.out Job <59305> is submitted to default queue <normal>.<<Waiting for dispatch ...>><<Starting on lsfhost.localdomain>>Host 0 -- ip 172.20.0.6 -- ranks 0Host 1 -- ip 172.20.0.7 -- ranks 1Host 2 -- ip 172.20.0.8 -- ranks 2host | 0 1 2======|================0 : SHM TCP TCP1 : TCP SHM TCP2 : TCP TCP SHMHello world! I'm 0 of 3 on opte6Hello world! I'm 1 of 3 on opte7Hello world! I'm 2 of 3 on opte8• This uses TCP/IP over the Elan subnet using the -TCP option in combination with the -subnet option for the Elan interface 172.22.x.x[user@opte10 user]$ bsub -I -n3 -ext "SLURM[nodes=3]" $MPI_ROOT/bin/mpirun -prot-TCP -subnet 172.22.0.10 -srun ./a.out Job <59307> is submitted to default queue<normal>.<<Waiting for dispatch ...>><<Starting on lsfhost.localdomain>>Host 0 -- ip 172.22.0.2 -- ranks 0Host 1 -- ip 172.22.0.3 -- ranks 1Host 2 -- ip 172.22.0.4 -- ranks 2host | 0 1 2======|================0 : SHM TCP TCP1 : TCP SHM TCP2 : TCP TCP SHMHello world! I'm 0 of 3 on opte2Hello world! I'm 1 of 3 on opte3Hello world! I'm 2 of 3 on opte4• Elan interface[user@opte10 user]$ /sbin/ifconfig eip0eip0 Link encap:Ethernet HWaddr 00:00:00:00:00:0Finet addr:172.22.0.10 Bcast:172.22.255.255 Mask:255.255.0.0UP BROADCAST RUNNING MULTICAST MTU:65264 Metric:1RX packets:38 errors:0 dropped:0 overruns:0 frame:0TX packets:6 errors:0 dropped:3 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:1596 (1.5 Kb) TX bytes:252 (252.0 b)• GigE interface[user@opte10 user]$ /sbin/ifconfig eth0eth0 Link encap:Ethernet HWaddr 00:00:1A:19:30:80inet addr:172.20.0.10 Bcast:172.20.255.255 Mask:255.0.0.0UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:133469120 errors:0 dropped:0 overruns:0 frame:0TX packets:135950325 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:24498382931(23363.4Mb) TX bytes:29823673137(28442.0Mb)Interrupt:31。
End-to-endargumentsinsystemdesign翻译
End-to-endargumentsinsystemdesign翻译设计系统中的端到端原则这篇论文提出了分布式系统中各模块间功能定位的设计原理，称为端到端原则，与底层内置的功能相比，那些系统低层提供的功能也许是冗余的或是无价值的。
例如在这篇论文中讨论过的位错误恢复、安全加密、复制消息抑制、系统崩溃恢复、交付确认等。
底层机制支持一些想性能增强这样合理的功能。
1.介绍确定功能间的边界对于计算机系统设计者来说可能是基本的行为。
对于系统设计者来说，最重要的工具是能够为功能定位决策提供指导的设计原则。
这篇论文讨论了多年使用却并没有明确定义的一类功能定位观点。
然而，随着数据通信网作为计算机系统组成成分的出现，通过其更清晰的应用环境和得以应用的原因形成了行功能布局。
该论文明确表述了这一论点，以便观察其本质并理解它实际上是怎样的。
这一观点吸引着应用需求，并为分层系统中的功能上移来靠近应用提供了基本原理，我们从通信网络版本开始思考。
在一个能够通信的系统中，通常会定义一个通信子系统的模块化边界和边界与系统之间的接口。
当这样做时，很显然存在一个通过多种方式可能实现的功能列表：通过通信子系统或是通过他们的客户，作为一种冒险，或者是冗余的，每次运行它们各自的版本。
之所以这样做，是因为应用需求为以下各类的观点提供的一个基础：考虑中的功能能够完全并正确的由常识在通信系统的端程序的帮助下实现，所以，将提供不确定的功能作为通信系统的特点是不可能的。
（有时一个不完整版本的通信系统提供的功能对于性能能够增强是有用的）这一系列的原因反对低层功能实现的端到端论点，以下部分来详细考察端到端论点，首先通过一个使用端到端的例子来研究——可靠的数据传输是考虑中的功能——并且通过展示功能的范围使得相同的论点可以得以应用。
在数据通信系统中，这个范围包括加密、重传信息检测、消息序列、有保证的消息传输、主机错误检测和交付回单。
在广阔的环境下，这一论点被应用于很多其他功能的计算机操作系统，包括自身的文件系统。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Parts submitted to: Journal of Logic and Algebraic Programming
The Interface Specification and Implementation Internals of a Program Module for Geometric Algebra
CONTENTS
Contents
1 Characteristic objects of geometric 1.1 Elementary blade . . . . . . . . . . 1.2 Homogeneous multivector . . . . . 1.3 Multivector . . . . . . . . . . . . . 1.4 Versor . . . . . . . . . . . . . . . . algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 4 4 5 6 6 7 7 8 10 12 12 14 16 18 19 21 21 23 24 24 28
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . ห้องสมุดไป่ตู้ . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
Intelligent Autonomous Systems Computer Science Institute Faculty of Science University of Amsterdam Kruislaan 403, 1098 SJ Amsterdam The Netherlands
Computer Science Institute Faculty of Science University of Amsterdam The Netherlands
This report describes a method to implement the main abstract operations characteristic to Clifford algebra. The design goal was to maintain the algorithms simple, their specifications correspond (mostly) to the basic definitions. The report is addressed to those who want to understand the low-level processing mechanisms underlying the abstract concepts of geometric algebra. Efficiency considerations did not prevail in the present implementation. The package presented is freely available (at source level) and may assist the development of C/C++ applications using the geometric algebra formalism. It could be easily extended in order to fit the specific requirements of a given application. Keywords: Clifford algebra, geometric algebra, abstract data type, program module, blade factorization
2 Classes of operations 2.1 Create/destroy operations . . . . . . . . . . . . . . . . . 2.2 Input/Output operations . . . . . . . . . . . . . . . . . 2.3 Conversions between representations of different entities 2.4 Unary operators . . . . . . . . . . . . . . . . . . . . . . 2.5 Unary predicates . . . . . . . . . . . . . . . . . . . . . . 2.6 Binary operators and related operations . . . . . . . . . 3 Implementation internals 3.1 The outer product implementation . . . . . 3.2 The geometric product implementation . . . 3.3 The inner product implementation . . . . . 3.4 The Delta product . . . . . . . . . . . . . . 3.5 Unoriented operators . . . . . . . . . . . . . 3.6 Orthogonal transformations . . . . . . . . . 3.7 Extensions specific to the conformal model 3.7.1 Basis conversion . . . . . . . . . . . 3.7.2 How is extension accomplished . . . 3.8 Orthogonal Factorization . . . . . . . . . . 4 Conclusions
tel: +31 20 525 7461 fax: +31 20 525 7490 http://www.science.uva.nl/research/ias/
Corresponding author: M.D. Zaharia tel: +31 (20) 525 7517 marius@science.uva.nl http://carol.science.uva.nl/~marius
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
Section 1
Characteristic objects of geometric algebra
1
This report considers already known the basics of Clifford algebra. The interested reader may follow [Hest 84], [Hest 86], [Hest 91], [Li 01]. The main difference between Clifford algebra and geometric algebra is that the latter emphasizes the geometric semantic of algebraic entities (blades, versors, different products etc.) From a formal point of view, the primitives whose implementation is described below are Clifford algebra primitives (they refer the pure algebraic manipulation) but the applications requiring their usage could belong to the geometric algebra field. That is why the reader should not be disturbed by the mixed appearance of both terms in this paper. It should not be considered a user manual. It concerns especially the internals of the implementation and the rational behind the design. More detailed information could be obtained directly from the source program that is freely available (http://carol.wins.uva.nl/∼marius). The present description of the program module (named GAP1 ) tries to initiate the reader to the detailed manipulation mechanisms specific to geometric algebra and to help him develop its own application programs using the abstract operations characteristic to a geometric algebra environment. A computer algebra system known to the geometric algebra research community is CLICAL (developed by P. Lounesto, [Loun 96]) it is mainly interactive and is supposed to familiarize the novice user with algebraic concepts such as complex numbers, quaternions or octonions and with their manipulation. Another approach, introducing the geometric algebra concepts is GABLE ([Mann 01]). It is an interactive, MATLAB based application that allows the user to describe algebraic computations and to visualize their geometric interpretation, limiting itself to geometric algebras defined for 3D Euclidean space. An interesting approach that can constitute the foundation of an implementation of Clifford algebra primitives is presented in [Abla 96]. In contrast with it, the present module treats mainly the case of non-degenerate Clifford algebras whose elements are expressed in an orthogonal basis (C p,q algebras). The implementation follows an ”algorithm driven” approach and this distinguishes it from the work of Ablamowicz ([Abla 96]) that could be considered ”data driven”. However the functionality of our package can be easily extended to support the case of ”Clifford algebras whose bilinear forms have antisymmetric parts” and to follow the implementation approach suggested in [Abla 96]. Sometimes the work in non-orthogonal bases can lead to more elegant interpretations of the results. That is why this report refers also to the possibility to extend the functionality of the present module in order to make it sufficiently flexible to satisfy the requirements of different applications. As an example the module GAP was extended to support the null basis of the conformal space. A simple way in that this particular extension was incorporated in the package is also presented here. This may constitute a model for analogous developments initiated by the end user.