Message protocol Test Case

合集下载

SoapUI教程：功能和非功能测试说明书

About the T utorialSoapUI is an open-source tool used for functional and non-functional testing, widely used in WebServices testing. This is a brief tutorial that introduces the readers to the basic features and usage of SoapUI. The tutorial will guide the users on how to utilize the tool in WebService and other non-functional testing.AudienceThis tutorial has been prepared for beginners to help them understand how to use the SOAPUI tool.PrerequisitesAs a reader of this tutorial, you should have a basic understanding of the client/server environment, and knowledge of SOAP, WSDL, XML, and XML namespace.Copyright & DisclaimerCopyright 2018 by Tutorials Point (I) Pvt. Ltd.All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy, distribute or republish any contents or a part of contents of this e-book in any manner without written consent of the publisher.We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our website or its contents including this tutorial. If you discover any errors on our website or inthistutorial,******************************************iT able of ContentsAbout the Tutorial (i)Audience (i)Prerequisites (i)Copyright & Disclaimer (i)Table of Contents ....................................................................................................................................... i i1.SOAP ─ INTRODUCTION (1)2.SOAP ─ MESSAGES (2)3.SOAP ─ WHAT IS REST? (4)4.SOAPUI ─ INTRODUCTIO N (5)5.SOAPUI ─ CAPABILITIE S (6)6.SOAPUI ─ NG PRO (8)7.SOAPUI ─ INSTALLATIO N & CONFIGURATION (9)8.SOAPUI ─ WSDL (19)WSDL Usage (19)Understanding WSDL (20)Format and Elements (20)WSDL – Port Type (22)Patterns of Operation (22)ii9.SOAPUI ─ PROJECT (26)Create a SOAP Project (26)Add a WSDL (28)Details View (30)10.SOAPUI – TESTSUITE (33)Creation of TestSuite (33)11.SOAPUI – TESTCASE (37)12.SOAPUI ─ TESTSTEP (39)13.SOAPUI ─ REQUEST & R ESPONSE (42)Request Setup (42)Response (42)HTTP Request (43)HTTP Response (44)14.SOAPUI ─ PRO PERTIES (46)Defining Properties (46)Accessing Property (47)15.SOAPUI ─ PROPERTY TRANSFER (49)Adding Property Transfer (49)Transferring a Property (50)iii16. SOAPUI ─ LOGS PANE (54)SOAP UI Log (55)HTTP Log (55)Error Log (56)Memory Log (56)17.SOAPUI – ASSERTIONS (57)18.ASSERTION ─ CONTAINS (60)19.ASSERTION ─ NOT CONT AINS (63)20.ASSERTION ─ XPATH MA TCH (65)21.ASSERTION – XQUERY MATCH (68)22.ASSERTION ─ SCRIPT (70)23.SOAPUI – TROUBLESHOOTING (74)24.SOAPUI ─ PERFORMANCE TESTING (76)Types of Performance Testing (76)Key Aspects in Web Service (76)25.SOAPUI ─ LOAD TESTIN G (78)Creation of Load Test (78)Execution of Load Test (79)Adding an Assertion (81)26.SOAPUI ─ RESTFUL WEB SERVICES (84)27.REST ─ PROJECT SETUP (85)iv28.REST ─ WADL (88)29.REST ─ REQUEST (90)30.REST ─ RESPONSE (94)31.REST ─ HTTP METHODS (97)POST (97)GET (97)PUT (98)PATCH (98)DELETE (99)32.SOAPUI ─ JDBC CONNEC TION (100)33.SOAPUI ─ JDBC PROPER TY (103)34.SOAPUI – JDBC ASSERTION (104)vSOAP is the acronym for Simple Object Access Protocol. It is defined by World Wide Web Consortium (W3C) at /TR/2000/NOTE-SOAP-20000508 as follows: SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it; a set of encoding rules for expressing instances of application-defined data types; and a convention for representing remote procedure calls and responses.SOAP ─ Important FeaturesFollowing are some important features of SOAP.∙It is a communication protocol designed to communicate via Internet.∙It can extend HTTP for XML messaging.∙It provides data transport for Web services.∙It can exchange complete documents or call a remote procedure.∙It can be used for broadcasting a message.∙It is both platform and language independent.∙It is the XML way of defining what information is sent and how.∙It enables client applications to easily connect to remote services and invoke remote methods.Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP. Other frameworks such as CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.1A SOAP message is an ordinary XML document containing the following elements:∙Envelope: Defines the start and the end of the message. It is a mandatory element.∙Header: Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end-point. It is an optional element.∙Body: Contains the XML data comprising the message being sent. It is a mandatory element.∙Fault:An optional Fault element that provides information about errors that occur while processing the message.All these elements are declared in the default namespace for the SOAP envelope: /2001/12/soap-envelopeThe default namespace for SOAP encoding and data types is:/2001/12/soap-encodingNote: All these specifications are subject to change. Thus, keep updating yourself with the latest specifications available on the W3 website.SOAP ─ Message StructureThe following block depicts the general structure of a SOAP message:233.REST is the acronym for Representational State Transfer. It can be defined as an architectural style of designing softwares. REST is not a specification or W3C standard. Hence, it is easier to work with RESTful Services. It doesn’t require any middleware specification framework.REST ─ Important FeaturesFollowing are some important features of REST.∙It relies on stateless, client-server, cacheable communication protocol – virtually in all cases, HTTP is used.∙It is light-weighted alternative of WebService and RPC (Remote Procedure Call) like SOAP-WSDL.∙It represents everything in unique ID or URIs.∙It makes the use of standard HTTP methods, such as GET, POST, PUT, DELETE.∙It links sources together.∙REST resources could have multiple representations.∙Any named information is considered as a Resource. For example: An image, a person, a document, all can be considered as an example of resource and represented as a unique ID or a URI.∙World Wide Web itself, based on HTTP, can be viewed as REST based architecture. REST services are Platform and Language independent. Since it is based on HTTP standards, it can easily work in the presence of firewalls. Like WebServices, REST doesn’t offer any in-built security, session management, QoS guarantee but these can be added by building on top of HTTP. For encryption, REST can be used on top of HTTPS.45SoapUI is a tool which can be used for both functional and non-functional testing. It is not limited to web services, though it is the de-facto tool used in web services testing.SoapUI ─ Important FeaturesFollowing are some important features of SoapUI.∙ It is capable of performing the role of both client and service.∙It enables the users to create functional and non-functional tests quickly and in an efficient manner using a single environment.∙ It is licensed under the terms of the GNU Leaser General Public Licence (LGPL).∙ It is purely implemented using JAVA platform.∙ It supports Windows, Mac, multiple Linux dialects.∙It allows testers to execute automated functional, regression, compliance, and load tests on different Web API.∙It supports all the standard protocols and technologies to test all kinds of APIs.SOAP UI can be used to test complete RESTful API and SOAP Web Service testing. It supports Functional Testing, Performance Testing, Interoperability Testing, Regression Testing, Load Testing, and much more.It is user friendly as well as it is easy to convert functional test into non-functional tests such as Load, Stress testing.6S OAP UI is rich in the following five aspects:∙ Functional Testing ∙ Security Testing ∙ Load Testing∙ Protocols and Technologies ∙Integration with other toolsLet’s learn more about each of these capabilities.Functional Testing∙ SOAP UI allows the testers to write functional API tests in SOAP UI.∙ SOAP UI supports Drag-Drop feature that accelerates the script development.∙SOAP UI supports debugging of tests and allows testers to develop data driven tests.∙SOAP UI supports multiple environments making it easy to switch among QA, Dev, and Prod environments.∙SOAP UI allows advanced scripting (the tester can develop their custom code depending on the scenarios).Security Testing∙ SOAP UI performs a complete set of vulnerability scan.∙ SOAP UI prevents SQL Injection to secure the databases.∙ SOAP UI scans for stack overflows, caused by documents huge in size.∙SOAP UI scans for cross-site scripting, which occurs when service parameters are exposed in messages.∙SOAP UI performs fuzzing scan and boundary scan to avoid erratic behavior of the services.Load Testing∙ SOAP UI distributes the load tests across n number of LoadUI agents. ∙ SOAP UI simulates high volume and real-world load testing with ease.∙SOAP UI allows advanced custom reporting to capture performance parameters.7∙SOAP UI allows end-to-end system performance monitoring.Protocols& TechnologiesSOAP UI supports a wide range of protocols:∙SOAP – Simple Object Access Protocol∙WSDL – Web Service Definition Language∙REST – Representational State Transfer∙HTTP – Hyper Text Transmission Protocol∙HTTPS – Hyper Text Transmission Protocol Secured∙AMF –Action Message Format∙JDBC – Java Database Connectivity∙JMS – Java Messaging ServiceIntegration w ith O ther T ools∙Apache Maven Project∙HUDSON∙JUnit∙Apache – Ant and more….6.SOAP UI is an open source free version tool with basic features of testing, while SOAP UI NG Pro is a commercialized tool having advanced features of reporting, data-driven functionality and much more.ComparisonThe following table compares and contrasts the various features of SoapUI and SoapUI NG Pro.897.SoapUI is a cross-platform tool. It supports Windows, Linux, and Mac operating systems.Prerequisites∙Processor: 1GHz or higher 32-bit or 64-bit processor.∙RAM: 512MB of RAM.∙Hard Disk Space: Minimum 200MB of hard disk space for installation.∙Operating System Version: Windows XP or later, MAC OS 10.4 or later.∙JAVA: JAVA 6 or later.Download ProcessStep 1: Go to https:/// and click Download SOAP UI.1011Step 2: Click ‘Get It’ to download SOAP UI Open Source. It will start downloading 112MB .exe file in the system. Wait till the download process is complete.12End of ebook previewIf you liked what you saw…Buy it from our store @ https://。

SECS-GEM PROTOCOL SPECIFICATION

SECS-GEM PROTOCOL PURCHASE SPECIFICATION PUR-STA(PURCHASING RULES SITE AGRATE)DOCUMENT HISTORYDOCUMENT APPROVALREFERENCED DOCUMENTSCUSTOM ATTRIBUTES Alternate NumberDispatcher VERGANIL Working Vault AGRStatus ACTIVECycle type ACTIVE Change designator REVALIDATION Customer N/A Department BACK_END Originator FARRUGIAMA Owner FARRUGIAMA Replication sites C29O8Wait for ChildrenRevalidation Date02-JUL-2012AppendixA SECS-GEM PROTOCOL SPECIFICATIONA.1 Applicable documentsA.2 IntroductionA.3 Physical communication requirementsA.4 SEMI Equipment communication standard 2 message content (SECS-II)A.5 GEM requirementsA.6 Exception HandlingA.7 Documentation structureA.8 SECS interface acceptance test1. APPLICABLE DOCUMENTSApplicable documents are the reference books created by SEMI Communication Committee for SECS. The purpose of these documents is to provide both the structure of the protocol anda common approach for its description.SECS is divided in two main layers: physical connection and logical connection.E4 SEMI Equipment Communication Standard 1 Message Transfer (SECS I)E37 High Speed SECS Message Services (HSMS) Generic ServicesE5 SEMI Equipment Communication Standard 2 Message Content (SECS II)E30 Generic Model for Communication and Control of SEMI Equipment (GEM)E90 Specification for Substrate TrackingE32 Material Movement Management (MMM)G84 Specification for Strip Map ProtocolE142 Specification for Substrate MappingThe physical connection can be addressed using or SECS-I either HSMS.SECS-I defines the physical link, block transfer protocol and message protocol, using a RS232 serial line. HSMS accomplishes the physical connection using a TCP/IP network protocol.SECS-I is described in the BOOK OF SEMI STANDARDS (EQUIPMENT AUTOMATION SOFTWARE 1 and 2) section E4-0699 "SEMI EQUIPMENT COMMUNICATIONS STANDARD 1 - MESSAGE TRANSFER (SECS-I)" (hereafter E4).HSMS is intended to cover the same functionality as SECS-I but it allows a much higher communication performances and it is described in the same BOOK OF SEMI STANDARDS in section E37-0303 "HIGH-SPEED SECS MESSAGE SERVICES (HSMS) GENERIC SERVICES" (hereafter E37).SECS-II defines the method of conveying information between equipment and host in the form of messages.It is described in the BOOK OF SEMI STANDARDS section E5-0703 "SEMI EQUIPMENT COMMUNICATION STANDARD 2 - MESSAGE CONTENT (SECS-II)" (hereafter E5).The GEM standard is an extension of SECS-II and defines which SECS-II messages should be used, in what situations, and what the resulting activity should be. Indeed SECS-II defines several standard functions and the related messages, but it does not specify the modeling of the equipment, that is what it is expected by the SECS protocol from a behavioral standpoint.The GEM standard is described in the section E30-0302 "GENERIC MODEL FOR COMMUNICATIONS AND CONTROL OF SEMI EQUIPMENT (GEM)" (hereafter E30).Substrate Tracking is described in the BOOK OF SEMI STANDARDS in the section E90-0703 “SPECIFICATION FOR SUBSTRATE TRACKING” (hereafter E90).The MMM standard is described in the BOOK OF SEMI STANDARDS (EQUIPMENT AUTOMATION SOFTWARE 1 and 2) section E32-0997 "MATERIAL MOVEMENT MANAGEMENT (MMM)” (hereafter E32).Strip Map Handling is described in the BOOK OF SEMI STANDARDS in the section G84-0303 “SPECIFICATION FOR STRIP MAP PROTOCOL” (hereafter G84).Substrate / Wafer Map Handling are described in the BOOK OF SEMI STANDARDS in the section E142-0305 “SPECIFICATION FOR SUBSTRATE MAPPING” (hereafter E142). SECSIM and SECSIM-PRO (by Asyst Technologies inc.) are software tools that are able to simulate (although not entirely) both the host (in order to develop the interfaces without direct connection to the equipment) and the equipment (in order to test the equipment itself). It is described in the "SECSIM User Manual".2. INTRODUCTIONThis document describes the requirements for the SECS communication protocol to be implemented in the assembly, testing and finishing equipment purchased by All STMicroelectronics Ltd. Back End Plants. It also specifies the structure of the documentation and the tests that will be performed to verify the equipment's SECS/GEM interface. Not all the listed communication protocol features may apply to specific equipment. However the equipment supplier should find that when making the compliance review of the present specification. In the scenario were a cell is made up of multiple equipment, any equipment in the cell is required to be capable for being integrated with the Host.2.1 General RequirementsThe SECS communication protocol software installed on the equipment, along with any other related software, must be Y2K compliant.2.2 Communication ProtocolThe required communication protocol is the S emiconductor E quipment C ommunication S tandard (hereafter SECS) defined by the SEMI (S emiconductor E quipment and M aterialsI nternational) Communication Committee (hereafter SEMI).2.3 Communication ModelIn order to use the equipment efficiently in an automated environment the SECS interface must satisfy a generic model of communication. The model that STMicroelectronics have chosen is GEM. By the physical point of view, HSMS is preferred to SECS-I especially when communication performances can become a critical issue (long recipes, recipes containing images, images, long tables or maps). For example, Die Bonder, Wire Bonder, Laser Marker and Testers equipment are required to be provided with HSMS.The SECS-GEM interface must allow different levels of equipment integration: it must be usable in a fully automated line but also in a traditional production environment. Indeed both the approaches may be used in STMicroelectronics in designing automation lines and control applications.In a fully automated environment the operator intervention must be limited to the resolution of equipment assist requests, while in a traditional line, without material movement management, the operator will be in charge to load the equipment and start them, therefore the SECS protocol will be used just to integrate the MES to the physical equipment, that is to take actions on the equipment and collect data from it as soon as specific transactions are performed by an MES client.2.4 Material Movement ManagementIn the automated lines the product is loaded on the equipment using dedicated Material Handling Systems (MHS). These systems are basically of two types:•In-line. The equipment is mechanically integrated with each other. There is not an external system to transport the product from equipment to equipment. In most casesthe single strip moves from equipment to equipment.•External. The equipment is standalone and the MHS is an independent system that transport product from one equipment to the other. Most often the product istransported in carriers. This also applies when a line is made up of several in-linesystems connected together using an independent MHS.The MMM protocol is required whenever an external MHS is used either to transfer product between standalone equipment or in-line systems. The usage of different protocols, like SMEMA (S urface M ount E quipment M anufacturers A ssociation described in SMEMA 1.2), is allowed only within the boundaries of an in-line system.3. PHYSICAL COMMUNICATION REQUIREMENTS3.1 SECS-ISECS-I defines the physical link, block transfer protocol and message protocol, using a RS232 serial line. It must exactly follow E4 SECS-I standards. Protocol parameters described in SEMI standards as being adjustable must comply exactly with the E4 standard. The system bytes in a reply message sent by the equipment must be equal to the system bytes of the host primary message the equipment is replying to. The system bytes of all blocks in a multi-block message must be the same.It is required that the equipment can handle concurrent open transactions.The equipment's communication parameters (SECS protocol parameters, equipment constants, etc.) must be saved in non-volatile memory in case of reset or power supply failure. Loss of the non-volatile memory must generate an alarm or event report. During equipment start-up (after boot or power supply failure) parameters concerning the SECS interface set previously must be re-activated. This includes equipment constants and SECS communication parameters. The method for changing the SECS-I parameters must be included in the SECS interface documentation and the SECS-I parameter configuration must be password protected.Whenever a piece of equipment is composed of more modules, the equipment control must be able to manage all the different modules. From the SECS standpoint, the equipment must be seen a single unit with only one SECS connection. However if equipment is integrated with another equipment example Laser Marker onto a Handler any of this equipment should be capable of being integrated with the Host Independently.3.2Documentation (SECS-I)For equipment or Host to comply with SECS-I, a document is required containing the following information. (See also SEMI E6-0303, GUIDE FOR SEMICONDUCTOR EQUIPMENT INSTALLATION DOCUMENTATION)1. Method for setting all the parameters in Table 1 (below).2. Range allowed and resolution for each parameter in Table 1 (below).3. Compatibility with duplicate block detection and the method for enabling and disablingthe same if present (See E4-0699 Section 7.4.2).4. Maximum Expected inter-character, protocol, reply, and inter-block delays generatedunder normal operating conditions.5. Whether multi-block message are supported as a receiver.6. Whether multi-block message are used as a sender.7. Whether there is a limit to the size of a message received and, if so, what the limit is.8. Maximum expected size of a message being sent.9. Whether message interleaving is supported as a receiver.10. Whether message interleaving is used as a sender.11. Number of Device ID’s supported on the port.12. Maximum number of supported concurrent open transactions.Reference E4-0699 Section 8 Parameter settings3.3 HSMSHSMS accomplishes the physical connection using a TCP/IP network protocol. It must exactly follow E37 HSMS standards. The equipment must be able to support periodic Linktest.req messages. Despite it is not required; the equipment may initiate periodic Linktest.req messages. The equipment must provide a password protected way to configure HSMS parameters. Those settings must be kept by the equipment on a non-volatile storage device and must be reloaded at each power failure or system software reloads. Multiple open transactions must be supported by the equipment entity.It is preferred that the equipment establish the TCP/IP connection using Passive Connect Mode.The documentation must include:•The method for setting protocol parameters (Including if the IP address is static or dynamic).•The ranges and units allowed for each parameter.•The option used for refusing incoming connection requests if the implementation uses Passive Connect Mode.•The maximum message size that can be received.•The maximum message size that can be sent.•The maximum number of supported concurrent open transaction that the HSMS implementation can handle (greater than 1).In case of Passive Connect Mode, multiple connection requests on a single published port are allowed anytime even if equipment is a cluster of independent modules provided with independent control system software. The reply matching criteria defined in E37 (9.4.1) must be strictly observed.3.4HSMS Reply Matching CriteriaWhen a Sender sends a Primary Message with W-Bit 1 (Reply Expected), the Sender should expect a Reply message whose header meets the following requirements.•The Session ID of the Reply must match the Session ID of the Primary Message.•The Stream of the Reply must match the Stream of the Primary Message.•The Function of the Reply must be one greater than the Function of the Primary Message, or else the Function of the Reply must be 0 (Function Zero Reply).•The System Bytes of the Reply must match the System Bytes of the Primary Message.4. SEMI EQUIPMENT COMMUNICATION STANDARD 2 MESSAGE CONTENT(SECS-II).The SEMI Equipment Communication Standard Part 2 (SECS-II) defines the details of the interpretation of messages exchanged between intelligent equipment and a host.The SECS-II is intended to be fully compatible with SEMI Equipment Communication Standard E4 SECS-I. It is also the intent to allow for compatibility with alternative message transfer protocols which adhere with protocol requirements contained in E5-0703 Section 3.SECS-II gives form and meaning to messages exchanged between equipment and host usinga message transfer protocol, such as SECS-I.SECS-II defines the method of conveying information between equipment and host in the form of messages. These messages are organized into categories of activities, called functions.SECS-II defines the structure of messages into entities called items and lists of items. This structure allows for a self-describing data format to guarantee proper interpretation of the message.The interchange of messages is governed by a set of rules for handling messages called the transaction protocol. The transaction protocol places some minimum requirements on any SECS-II implementation (See E5-0703 Section 5.3).STMicroelectronics requires that all messages exchange between equipment and host comply with SEMI Standards E5-0703.For any received message that cannot be processed, the equipment must send the appropriate error message on stream 9.Upon detection of a transaction timeout, the equipment should send S9F9 to the host.Upon receipt of function 0 as a reply to a primary message, the equipment must terminate successfully the related transaction, without any error sent to the host.SECS-II must support block interleaving for multi-block messages when based on SECS-I layer.5. GEM REQUIREMENTSSTMicroelectronics requires GEM as the standard implementation of SECS-II.The equipment must be a GEM Compliant machine in the terms specified in E30 standard.This means that:• The fundamentals GEM requirements are satisfied.• Each capability is implemented to conform to all applicable definitions, descriptions, and requirements defined for the capability in E30.Regarding some GEM capabilities we want to stress the following points.1. The level of the equipment on board automation must allow for running the equipment usingSECS commands without requiring the operator intervention. However While the equipment is in production mode, the operator should still be able to intervene in case of emergency and to perform minor process related adjustments on the equipment, stop the equipment and clear the alarms.2. While running in automatic mode, regardless of the control state, any change in productionparameters and machine configuration must generate dedicated event reports that allow identification of changed parameters together with corresponding new value.3. The host system will not replace the equipment functionality via SECS, that is, it will notimplement functions that during offline or local equipment operation are performed by the equipment control software itself. SECS conversations will send requests to the equipment controller software to perform macro actions such as 'prepare to process a lot'. Micro actions, such as opening a relay or step a lifter, are not performed through the SECS interface but by the equipment control software once it has received a macro action. Moreover the host system is not expected to take on any type of equipment diagnostic or maintenance functions using the SECS interface.4. Host interface and operator interface must have the same functionality during production inremote control state: the host must be able to access the same functions an operator can access from the equipment terminal during error free operations and vice versa. Moreover, while in remote control, any command initiated by the operator must trigger the sending of a related event report.5. The equipment may supply additional functionality not specified in the GEM standard aslong as it does not conflict with compliance to GEM capabilities.For a definition of the terms fundamental requirements and capability see E30. Table 2 summarizes the GEM fundamental requirements and additional capability required for equipment types. According to the Production needs, an equipment may not be equipped with the full below defined capabilities.Table 2 GEM fundamental requirements and additional capabilityImportant: The Die Picked Event is not required if E142 is implemented. The information will be available in the Transfer Map.Important:The Enabling / disabling concept of the start button is to have the Start Button disabled as soon as the lot have done Track out or Track in cancel and to enable the Start Button only when a successful lot Track in occurs.Equipment Integration controller to enable the START button on the equipment via the SECS-II message S2F15 with the following data items:8ECID = <ECID>8ECV = <ECV>5.1 STMicroelectronics specific GEM RequirementsThis section explains some outlines, limitations and further requirements to the GEM and to the specifications of SECS-II not explicitly mentioned in the GEM standard.The supplier may define new streams and functions for custom tasks as long as he respects the standard structure and allowed stream and function codes if so all the custom Stream and Functions must be fully and clearly documented in the equipment SECS-GEM manual. However, it is strongly desirable that the supplier use the basic standard streams and functions pre-defined in E5.5.1.1 Process Program ManagementAll process programs residing on the equipment and all associated tables or data that are used while the machine is in production must be supported (downloaded/uploaded) by the "Process Program Management" capability. Moreover, the equipment of the same model must be able to share process programs and all the related tables that are required in production. (See E30-0703 Section 4.6.4)The recipe downloaded by the host while the equipment is in remote control state must be suitable to execute also if the equipment was switched to local control state and it must be shown on the equipment display i.e. the recipe must be stored and executed on the local non-volatile storage.5.1.2 Event Report NotificationNo hardcode or “canned” reports are allowed. Dynamic report configuration is required.The following collection events (CEID) are required:•Product process start.•Product process stops.•Save of a recipe on the equipment hard disk.•Change of a configuration parameter (ECID) by the machine console.•Process step start and completion (when process programs are composed of more process steps).•Process completion of a strip.•Process start of a strip.•Process completion of the product contained in an input carrier (for any type of carrier or cassette or tube or tray).•Carrier (or cassette or tube or tray) load in the input process position.•Empty carrier (or cassette or tube or tray) load in the output process position.•Carrier (or cassette or tube or tray) unloads from the output process position. •Operator command executed.•Loss of configuration.•An input buffer becomes empty (for any type of carrier, cassette, tube or tray both full and empty).•An output buffer becomes full (for any type of carrier, cassette, tube or tray both full and empty).• A material required to the process has been exhausted, for any type of material.•Unique CEIDs for each event.•CEID for maintenance and down state•CEID for production state•CEID for process state change•CEID for equipment OFF-LINEThe equipment supplier must provide documentation of all collection events defined on the equipment and the conditions for each event to occur (see E30-0703 Section 4.2.1.1.4) 5.1.3 Variable Data CollectionIt is required that any input and output parameter relevant for the process monitoring and control is available as a SECS communication Variable ID.The following VIDs are required depending on the type of process:•PPID of the last recipe saved on the equipment hard disk.•PPID of the recipe currently in process.•ECID of the last configuration parameter changed by equipment console.•StripID of the strip in process at a machine module (for each module).•ID of the carrier or cassette or tube or tray in the input process position(s).•ID of the carrier or cassette or tube or tray in the output process position(s).•Last command executed by the operator.•Device scraps (uncompleted) count in the last strip completed.•Device scraps (uncompleted) count in the strip currently in process.•Device or position skipped count in the last strip completed.•Device or position skipped count in the strip currently in process.•Device processed count in the last strip completed.•Device processed count in the strip currently in process.•Device scraps (uncompleted) count in the last carrier completed.•Device scraps (uncompleted) count in the carrier currently in process.•Device or position skipped count in the last carrier completed.•Device or position skipped count in the carrier currently in process.•Device processed count in the last carrier completed.•Device processed count in the carrier currently in process.•Strip processed count in the last carrier completed.•Strip processed count in the carrier currently in process.•Total count of good devices.•Total productive uptime.•Total standby time.•Total downtime.•Start button status enabled or disabled.If the equipment is required to handle strip / substrate mapping all Data variables stated in the SEMI standard E90, G84 or E142 must be provided.5.1.4 Establish CommunicationThe equipment may poll the host to determine if the line is still active while in the GEM communicating state. The SECS interface must include a method to disable polling and to adjust the polling interval.The Equipment must provide the Establish Communications Timeout Equipment constant as described in the Gem document E30.5.1.5 Remote ControlManual intervention must never be required to initiate any given host action. Therefore any remote command or any other host message must be accepted by the equipment regardless the status of the operator interface.As an extension of E30 chapter 4.4.4, the following remote commands must be implemented (refer to SEMI Standard document E30 to obtain detailed supporting information)1) PROCESS PROGRAM SELECTDescription: the process program is retrieved from the disk and loaded intoworking memory.2) STOPDescription: stops the equipment at the end of a safe cycle for product that is atthe end of a cycle where product is not damaged or scrapped. (Stop after currentDevice, Block or Strip depending on the product cycle).3) STOP AND CLEARDescription: stops unloading product from the input carrier, completes the processof the entire product on the equipment, loads this product in the output carrier andstops.4) STOP AND UNLOADDescription: like “STOP AND CLEAR” and unloads the input and output carriers.5) STOP NEXTDescription: completes the process of the product in the input carrier loading it intothe output carrier and stops.6) RUN ONE CARRIERDescription: starts and completes the process of the product into the input carrier,loads it into the output carrier and stops. The identification of the carriers in theinput and output process locations must NOT be a result of this command.7) IMMEDIATE STOPInstantly Equipment stops.Description:8) START BUTTON ENABLING / DISABLINGDescription: This feature is required so that the EIC is able to prevent the userfrom starting the equipment without having the necessary validations completed.5.1.6 Control State ModelAll capabilities that are available to the operator when the "local control" state is active should be available to the host when the "remote control" state is active. For each of the operator commands a specific Collection Event ID will be generated by the equipment, allowing the cell controller to track operator actions. This is a minimum requirement, while it is advisable that the operator capability level in "remote control" is configurable using equipment configuration parameters. Please, refer to E30 chapter 3.3 for details. These configuration parameters must be available also as SECS constants (ECID).5.1.7 Process state modelThe equipment supplier is required to use the GEM Processing State Model as a reference and to adopt it to the specific characteristics of the equipment.5.1.8 Alarm ManagementThe capability of clearing the pending alarms must be always available by the equipment to the operator, regardless of the communication state. As an extension of E30 chapter4.3.4, the following functionality must be implemented:•List currently set alarms.•Alarms concerning Strip Mapping.•Alarms concerning Wafer Mapping.•Alarms concerning Recipe Management.•Process Specification Alarms.•Equipment Related Alarms.The equipment manufacturer must define for the equipment a set of alarms relating to the physical safety limits of operator, equipment, or material being processed.The equipment must maintain all enable/disable states and report definitions for alarms and collection events in non-volatile memory.Each alarm defined on the equipment must have a brief description of its meaning, an associated unique alarm identifier (ALID), alarm text (ALTX), an alarm status (ALCD) and two unique collection event identifiers (CEIDs), one for set and one for cleared.Enabled alarm reports must be sent prior to corresponding enabled event reports.For each enable alarm the S5F1 message must be transmitted within 2seconds from the time at which the alarm occurred on the equipment.The equipment must continue to transmit alarm messages (S5F1) even if the control state is LOCAL.All reports states and enable/disable status of alarm must be stored in none volatile storage.All Alarms must comply with the Alarm Management GEM Standard E30 Section 4.35.1.9 Product ManagementThe equipment must always maintain the carrier integrity: strips coming from one carrier must not be loaded in a carrier containing strips coming from a different carrier. This is a mandatory capability and must not affect equipment capacity and throughput.The product can be loaded in carriers, strips, tubes or trays. It is assumed that these containers are codified using bar codes, matrix codes or other ID systems. The code to be read will be defined in a separate document which will be supplied with this specification. It may be either of CarrierID or, a StripID or, a TubeID and a TrayID.The equipment must be able to identify the product at specific equipment locations using bar code readers or other lot identification systems. It is mandatory that the equipment can identify the carriers in the input and output process locations.The equipment control software must contain a definition of machine locations where material can be stored on board. When the equipment receives product in carriers, the location should define the place where a carrier can be stored. If the equipment receives the product as single strips, the location should define the place where a strip is stored.Similar requirement applies to tubes and trays.The equipment SECS interface should be able to report the status of all the material (product) on board using the S3,F1 / S3,F2 messages. Moreover the equipment should be able to detect and report when an unexpected material is found on the equipment or an expected material has been lost. The messages to be used for this purpose are: S3,F5 / S3,F6 / S3,F7 / S3,F8.5.1.10 Data CollectionFor measurement equipment, the host must be able to change the sampling sequence (strip and die co-ordinates) regardless of the measurement recipe. In the case of re-measure the host can re-specify the sampling sequence without sending a new recipe.Different recipes must be available for selection for different carrier slots/devices.Moreover, the equipment must keep on measuring when a slot where a strip was expected is found empty. In this later case a specific Collection Event ID must be initiated by the equipment.5.1.11 SpoolingSpooling is a capability whereby the equipment can queue messages intended for the host during periods of communication failure and subsequently deliver these messages when communication is restored. Spooling is limited to primary messages of user-selected streams. Spooling on the equipment must comply with the requirements in the GEM (E30) Standard section 4.11.4.Equipment must provide a spooling capability, it must also provide the host with the ability to enable and disable Spooling for any message (except Stream 1 messages, i.e. S1,F1, S1,F13) via the S2,F43/F44 transaction. Spooling may be enabled for an entire Stream, for individual messages within a stream, or for any combination of the two. Streams and Functions not referenced in this message are not spooled. Spooling can be totally disabled by sending an S2,F43 with a zero length list for the first item.。

RFC2889——拥塞控制测试

·端口1 50%拥塞
·端口2 100%拥塞
选择测试参数
时间
·开始发送流量之前等待2秒
·停止发送流量之后等待10秒
结果保存路径
·默认路径
·可以自己指定
时延
·本项测试不关注
启用学习
·二层学习
·频率可自定义
配置拥塞控制参数
测试时长
·默认1次
·默认60秒
负载
·100%速率测试
·使用最大速率
帧长度
·默认取7个特殊字节来测试
·太过详细
·可以选择汇总模板
·只保存汇总信息
测试报告内容
打开测试报告
·查看列头拥塞(Head of Line Blocking)
·查看拥塞控制(Backpressure列)
·配置信息:包含当前的测试配置信息
错误结果1
错误结果2
·无列头阻塞:拥塞端口对非拥塞端口无影响,非拥塞端口不丢包
拥塞控制测试流程
添加机框→预约端口→选择向导→选择拥塞控制→配置接口→配置流量→配置测试参数→配置拥塞控制参数→运行测试→查看结果→导出报告
准备工作:添加机框
准备工作:预约端口
启用Flow Control
·选择所有端口
·右键,选择”配置端口”
·广播帧转发和时延（Broadcast Frame Forwarding and Latency）。
接下来将为您演示使用BigTao-V网络测试仪进行拥塞控制测试。
二、拥塞控制概述
1.拥塞控制
拥塞控制测试项包含两个测试内容
·拥塞控制:一个DUT是否执行拥塞控制(背压/反压)
·列头拥塞:一个拥塞的端口是否会影响到另一个没有拥塞的端口
·当DUT处理完报文以后,可以发送Pause帧,让测试仪恢复发送

J1939 protocol英文版_最权威

6COMMUNICATION PROTOCOLSSection Page 6.1OVERVIEW.............................................................................................6-2 6.2SAE J1939MESSAGES AND MESSAGE FORMAT..............................6-26.1OVERVIEWThe key component of the DDEC10system is the serial communication link SAE ing this communication link allows the following functionality:□Transmitting sensor information via the data link at regular intervals and/or upon request to obtain data and to monitor for failures□Sharing information between stand-alone modules used in the system via the data link□Sharing engine data with electronic dashboard displays and vehicle management information systems via the data link□Transmitting and performing diagnostic procedures from external instrumentation such as the hand-held diagnostic data readers or DDDL via the data link□Transmitting customer requested changes to the CPC2+from external instrumentation via the data link□Transmitting to the powertrain the messages assigned to both the engine and the transmission retarder.The following industry standard Society of Automotive Engineers(SAE)documents can be used as a reference:□SAE J1708,Serial Data Communications Between Microcomputer Systems In Heavy Duty Vehicle Applications□SAE J1939/71,Vehicle Application Layer□SAE J1939,Top Layer(Overview)□SAE J1939/01,Truck and Bus Applications□SAE J1939/11,Physical Layer□SAE J1939/21,Data Link Layer□SAE J1939/73,Application Layer DiagnosticsTo obtain a copy of the above documents contact the Society of Automotive Engineers(SAE). SAE International400Commonwealth DriveWarrendale,PA15096Attention:PublicationsPhone:(412)776-49706.2SAE J1939MESSAGES AND MESSAGE FORMATJ1939(+),J1939(-),and J1939Shield are used as the J1939communication link.The message format uses the parameter group number as the label for a group of parameters. Each of the parameters within the group can be expressed in ASCII,as scaled data,or as function states consisting of one or more Bits.Alphanumeric data will be transmitted with the most signiﬁcant byteﬁrst.Other parameters consisting of two or more data bytes shall be transmitted least signiﬁcant byteﬁrst.The type of data is also identiﬁed for each parameter.The following sections identify the parameters that are supported by DDEC10.The J1939source address can be set for various components as listed in the following table.ParameterParameter Options Default Access Group1EBC1Source Address SAE J19390–25533VEPS,DRS 1TSC1Source Address SAE J19390–255231VEPS,DRS 1CC1Source Address SAE J19390–25523VEPS,DRS 1CC2Source Address SAE J19390–25533VEPS,DRS 1CC3Source Address SAE J19390–25549VEPS,DRS 1CM1DPF Source Address SAE J19390–25549VEPS,DRS 1CM1Fan Source Addr1SAE J19390–25549VEPS,DRS 1CM1Fan Source Addr2SAE J19390–25549VEPS,DRS Table6-1J1939Source AddressPGNMessage Name Acronym(dec)From SA61(ACM2):64946Aftertreatment1Intermediate Gas AT1IMG64908Aftertreatment1Gas Parameters AT1GP61455Aftertreatment1Outlet Gas1AT1OG1Table6-2ACM2Address J1939MessagesPGN(dec)Message Name Acronym From SA1(MCM2):65194Alternate Fuel2AF264981Electronic Engine Controller5EEC564931Electronic Engine Controller6EEC664916Electronic Engine Controller7EEC765243Engine Fluid Level/Pressure2EFL/P261450Engine Gas Flow Rate EGF165170Engine Information EI65129Engine Temperature3ET364870Engine Temperature4ET464976Inlet/Exhaust Conditions2IC265244Idle Operation IO65154Ignition Timing1IT165155Ignition Timing2IT265159Ignition Timing6IT665178Turbocharger Information2TCI265177Turbocharger Information3TCI365176Turbocharger Information4TCI465175Turbocharger Information5TCI565245Turbocharger TCTable6-3MCM2Address J1939MessagesPGN (dec)PGN(hex)Message Name Acronym65135FE6F Adaptive Cruise Control ACC1 60928EE00Request For Address Claimed ACL 61183EEFF Address Claimed ACL 65269FEF5Ambient Conditions AMB 65265FEF1Cruise Control Vehicle Speed CCVS 57344E000Cab Message#1CM1 65226FECA Active Diagnostic Trouble Codes DM1 65235FED3Diagnostic Data Clear/Reset for active DTC's DM11 57088DF00Stop Start Broadcast DM13 65228FECC Diagnostic Data Clear DM3 61441F001Electronic Brake Controller#1EBC1 65215FEBF Wheel Speed Information EBC2 61443F003Electronic Engine Controller#2EEC2 61440F000Electronic Retarder Controller#1ERC165281FF02Engine Start Stop(Daimler Prop)ESS(Prop02) 61442F002Electronic Transmission Controller#1ETC1 61445F005Electronic Transmission Controller#2ETC2 65098FE4A Electronic Transmission Controller#7ETC7 55809DB00UDS Functional ISO15765_Funct 55808DA00UDS Physical ISO15765_Phys 61184EF00Proprietary XCP PropA 65280FF00Proprietary UDE PropB00 65530FFFA Proprietary Malaysian H/W Test PropB00 65283FF03Proprietary message KWP Gateway PropB03 65297FF11Proprietary message for FUSO PropB11 65313FF21Proprietary message SAM CAB A1PropB21 65314FF22Proprietary message SAM CAB A2PropB22 65316FF24Proprietary message for FUSO PropB24 65380FF64Proprietary message for Predictive CC PropB64 65381FF65Proprietary message for Predictive CC PropB65 65264FEF0Power Takeoff Information PTO65275FEFB Retarder Fluids RF59904EA00Request PGN RQST 65099FE4B Transmission Conﬁguration#2TCFG2 65132FE6C Tachograph#1TCO1 00Torque Speed Control#1TSC1 65103FEF4Vehicle Dynamic Stability Control1VDC1 Table6-4SAE J1939Supported Incoming CPC2+MessagesPGN (dec)PGN(hex)Message Name Acronym65135FE6F Adaptive Cruise Control#1ACC1 60928EE00Request For Address Claimed ACL 59392E800Ack/Nack ACK/NACK 61183EEFF Address Claimed ACL 61183EEFF Cannot Claim Address ACL 64912FD90Advertised Engine Torque Curve AETC 65269FEF5Ambient Conditions AMB 64947FDB3Aftertreatment Outlet Gas#2AT1OG2 65110FE56Aftertreatment1SCR Tank1Inform AT1T11 65261FEED Cruise Control/Vehicle Speed Setup CCSS 65266FEF1Cruise Control/Vehicle Speed CCVS 65259FEEB Component Identiﬁcation CI57344E000Cab Message#1CM1 64775FD07Direct Lamp control Command1DLCC1 65226FECA Active Diagnostic Trouble Codes DM1 65227FECB Previously Active Diagnostic Trouble Codes DM2 61441F001Electronic Brake Controller#1EBC1 65251FEE3Engine Conﬁguration EC 61444F004Electronic Engine Controller#1EEC1 61443F003Electronic Engine Controller#2EEC2 65247FEDF Electronic Engine Controller#3EEC3 65214FEBE Electronic Engine Controller#4EEC4 65263FEEF Engine Fluid Level/Pressure#1EFL_P1 65243FEDB Engine Fluid Level/Pressure#2EFL_P2 61440F000Electronic Retarder Controller#1ERC1 65262FEEE Engine Temperature#1ET1 65188FEA4Engine Temperature#2ET2 65213FEBD Fan Drive FD 65253FEE5Engine Hours,Revolutions HOURS 65270FEF6Inlet/Exhaust Conditions#1IC1 64976FDD0Inlet/Exhaust Conditions#2IC2 65244FEDC Idle Operation IO 56064DB00UDS Functional ISO15765_Func 55808DA00UDS Physical ISO15765_Phys 65257FEE9Fuel Consumption LFC 65266FEF2Fuel Economy(Liquid)LFE 64892FD7C Particulate Trap Control#1PTC1 65264FEF0Power Takeoff Info PTO 65249FEE1Retarder Conﬁguration RC 65252FEE4Shutdown SHUTDN 65242FEDA Software Identiﬁcation SOFT 65245FEDD Turbocharger TC 65132FE6C Tachograph TCO1 65254FEE6Time/Date TD 65248FEE0Vehicle Distance VD 65217FEC1High Resolution Vehicle Distance VDHR 65271FEF7Vehicle Electrical Power VEP 65255FEE7Vehicle Hours VH 65260FEEC Vehicle Information VI 65279FEFF Water in Fuel Indicator WFI 61436EFFC Proprietary XCP PropA65280FF00Proprietary Malaysian H/W Test PropB00 65280FF00Proprietary UDE PropB00 65282FF02Proprietary for FUSO PropB02 65361FF51Proprietary for FUSO PropB51 65376FF60Proprietary for Predictive CC PropB60 Table6-5SAE J1939Supported Outgoing CPC2+Messages6.2.1SAE J1939SUPPORTED MESSAGESThe format of SAE J1939supported messages may be seen in the following sections.6.2.1.1ACC1–Adaptive Cruise ControlReception rate:100msTransmission rate:1secondData length:8bytesData Page:0PDU format:254PDU speciﬁc:111PGN:65135(0x00FE6F)Byte:1Speed of Forward Vehicle-N/AByte:2Distance to Forward Vehicle-N/AByte:3Adaptive Cruise Control Set Speed-N/AByte:4ACC Status1Bits:8,7Not DeﬁnedBits:6-4Adaptive Cruise Control Set Distance Mode-N/ABits:3-1Adaptive Cruise Control Mode(SPN1590)110:Error111:Not AvailableByte:5–6Road Curvature-N/AByte:7Bits:8,7Not DeﬁnedBits:5,6ACC Distance Alert Signal–N/ABits:3,4ACC System Shutoff Warning–N/ABits:1,2ACC Target Detected–N/AByte:8Not Deﬁned6.2.1.2ACK/NACK–Acknowledge/Negative Acknowledge Transmission Rate:As NeededData Length:8bytesData Page:0PDU format:232PDU speciﬁc:Destination AddressDefault priority:6PGN:59,392(0x00E800)Byte:1Control Byte0:Positive Acknowledgment(ACK)1:Negative Acknowledgment(NACK)2:Access Denied(PGN supported but access denied) Byte:2Group Function Value(if applicable)-N/ABytes:3–5Reserved for assignment by SAE,send each of these bytes as“FF”Byte:6–8Parameter Group Number of requested information6.2.1.3AETC-Advertised Engine Torque CurveTransmission RepetitionRate:N/AData Length:VariableData Page:0Extended Data Page:0PDU format:253PDU speciﬁc:144PGN Supporting Information:Default priority:6PGN:64,912(0xFD90)Start Position Length Parameter Name SPN 1.14bits AETC Data CollectionStandard35581.54bits Number of AETC datapoints3559a2bytes AETC Speed Value3560b2bytes AETC Torque value35616.2.1.4AMB–Ambient ConditionsTransmission Rate:1sec.Data Length:8bytesData Page:0PDU format:254PDU speciﬁc:245Default priority:6PGN:65,269(0x00FEF5)Byte:1Barometric Pressure(SPN108)Resolution:0.5kPa/Bit,0kPa offsetByte:2Cab Interior Temperature-N/ABytes:4,5Ambient Air Temperature(SPN171)Resolution:0.03125°C/Bit,-273°C offsetByte:6Air Inlet Temperature(SPN172)Resolution:1°C/Bit,-40°C offsetBytes:7,8Road Surface Temperature-N/A6.2.1.5ATI2-Aftertreatment Intake Gas2Transmission Repetition Rate:500msData Length:8bytesExtended Data Page:0Data Page:0PDU format:253PDU speciﬁc:180Default priority:6PGN:64948(0xFDB4)Bytes:1–2Exhaust Gas Temperature1(SPN3241)–N/ABytes:3–4Particulate Trap Intake Gas Temperature(SPN3242)(CPC2+Rel2or later) Resolution:0.03125°C/Bit,-273°C offsetByte:5Exhaust Gas Temperature1Preliminary FMI(SPN3243)–N/AByte:6Particulate Trap Intake Exhaust Gas Temperature Preliminary FMI–N/A6.2.1.6ATO2-Aftertreatment Outlet Gas2Transmission Repetition Rate:500msData Length:8bytesExtended Data Page:0Data Page:0PDU format:253PDU speciﬁc:179Default priority:6PGN:64947(0xFDB3)Bytes:1–2Exhaust Gas Temperature3(SPN3245)–N/ABytes:3–4Particulate Trap Outlet Gas Temperature(SPN3246)(CPC2+Rel2or later) Resolution:0.03125°C/Bit,-273°C offsetByte:5Exhaust Gas Temperature3Preliminary FMI(SPN3247)–N/AByte:6Particulate Trap Outlet Exhaust Gas Temperature Preliminary FMI–N/A 6.2.1.7CCSS–Cruise Control/Vehicle Speed SetupTransmission Rate:On RequestData Length:8bytesData Page:0PDU format:254PDU speciﬁc:237Default priority:6PGN:65,261(0x00FEED)Byte:1Maximum Vehicle Speed Limit(SPN74)Resolution:1km/h/Bit,0km/h offsetByte:2Cruise Control High Set Limit Speed.(SPN87)Resolution:1km/h/Bit,0km/h offsetByte:3Cruise Control Low Set Limit Speed(SPN88)Resolution:1km/h/Bit,0km/h offsetBytes:4-8Not Deﬁned6.2.1.8CCVS–Cruise Control/Vehicle SpeedTransmission/Reception Rate:100msData Length:8bytesData Page:0PDU format:254PDU speciﬁc:241Default priority:6PGN:65,265(0x00FEF1)Byte:1Measured_SW1Bits:8,7Not DeﬁnedBits:6,5Cruise Control Pause Switch(SPN1633)00:Off01:On10:Error11:Take No ActionBits:4,3Parking Brake Switch(SPN70)00:Park Brake Not Set01:Park Brake Set10:Error11:Not ConﬁguredBits:2,1Two Speed Axle Switch(SPN69)00:Low Speed Range01:High Speed Range10:Error11:Not ConﬁguredByte:2,3Wheel Based Vehicle Speed(SPN84)Resolution:1/256km/h,0km/h OffsetByte:4Measured_CC_SW1Bits:8,7Clutch Switch(SPN598)00:Clutch Pedal Released01:Clutch Pedal Depressed10:Error11:Not ConﬁguredBits:6,5Service Brake Switch(SPN597)00:Brake Pedal Released01:Brake Pedal Depressed10:Error11:Not ConﬁguredBits:4,3Cruise Control Enable Switch(SPN596)00:Cruise Control Disabled01:Cruise Control Enabled10:Error11:Not ConﬁguredBits:2,1Cruise Control Active(SPN595)00:Cruise Control Off01:Cruise Control On10:Error11:Not ConﬁguredByte:5Measured_CC_SW2Bits:8,7Cruise Control Accelerate Switch(SPN602)00:Accelerate Switch Off01:Accelerate Switch On10:Error11:Not ConﬁguredBits:6,5Cruise Control Resume Switch(SPN601)00:Resume Switch Off01:Resume Switch On10:Error11:Not ConﬁguredBits:4,3Cruise Control Coast Switch(SPN600)00:Coast Switch Off01:Coast Switch On10:Error11:Not ConﬁguredBits:2,1Cruise Control Set Switch(SPN599)00:Set Switch Off01:Set Switch On10:Error11:Not ConﬁguredByte:6Cruise Control Set Speed(SPN86)Resolution:1km/h/Bit,0km/h OffsetByte:7State_CCBits:8–6Cruise Control State(SPN527)000:Off/Disabled001:Hold010:Accelerate011:Decel/Coast100:Resume101:Set110:Accelerator Override111:Not AvailableBits:5-1PTO State-(SPN976)00000:Disabled/Off00001:Hold00010:Remote Hold00100:Remote Standby00101:Set00110:Decelerate/Coast00111:Resume01000:Accelerate01001:Accelerator Override01010:Programmed Speed101011:Programmed Speed201100:Programmed Speed311111:Not AvailableByte:8Measured_Idle_SW1Bits:8,7Engine Shutdown Override Switch(SPN1237)00:Switch Off01:Switch On11:Not ConﬁguredBits:6,5Engine Test Mode Switch–N/ABits:4,3Idle Decrement Switch(SPN967)00:Off01:OnBits:2,1Idle Increment Switch(SPN968)00:Off01:On6.2.1.9CI–Component IdentiﬁcationTransmission Rate:On RequestData Length:37bytesData Page:0PDU format:254PDU speciﬁc:235Default priority:6PGN:65,259(0x00FEEB)Bytes:1-5Make(SPN586)–ASCIIByte:6*-DelimiterBytes7–14:Engine Model Number(SPN587)–ASCIIByte:15*-DelimiterByte:16–25Engine Serial Number(SPN588)–ASCIIByte:26*-DelimiterByte:27–36Unit Number(Power Unit)(SPN233)-ASCIIByte:37*-DelimiterNote:DDEC10also supports an alternate format of the component identiﬁcation data to satisfy an AGS2transmission.6.2.1.10CM1–Cab Message1 TransmissionRate:1sec.Data Length:8bytesData Page:0PDU Format:224PDU Speciﬁc:218Default Priority:6PGN:57,344(0x00E00016)Byte:1Requested Percent Fan Speed(SPN986)Resolution:0.4%/Bit,0offsetBytes:2–3Cab Interior Temperature Command–N/AByte:4Bits:2–1Auxiliary Heater Coolant Pump Request–N/ABits:4–3Battery Main Switch Hold Request–N/ABits:6–5Operator Seat Direction Switch–N/ABits:8–7Seat Belt Switch–N/AByte:5Bits:8–7Vehicle Speed Governor Enable Switch—N/ABits:6–5Vehicle Limiting Speed Governor Increment Switch–N/ABits:4–3Vehicle Limiting Speed Governor Decrement Switch–N/ABits:2–1Not DeﬁnedByte:6Bits:4–3Particulate Trap Regeneration Force Switch(SPN3696)00:Not Active01:Active10:Error11:Not AvailableBits:2–1Particulate Trap Regeneration Inhibit Switch(SPN3695)00:Not Active01:Active10:Error11:Not AvailableByte:7Bits:8–7Request Cab Zone Heating—N/ABits:6–5Request Engine Zone Heating–N/ABits:4–1Auxiliary Heater Mode Request–N/AByte:8Selected Maximum Vehicle Speed Limit–N/A6.2.1.11DD-Dash Display(PGN65276(R)Reception Rate:1sData Length:8Extended Data Page0Data Page:0PDU Format:254PDU Speciﬁc:252Default Priority:6PGN:65276(0xFEFC)Byte:1Washer Fluid Level(SPN80)-N/A Byte:2Fuel Level1(SPN96)Resolution:0.4%bit,0offsetByte:3Engine Fuel Filter Differential Pressure(SPN95)-N/AByte:4Engine Oil Filter Differential Pressure(SPN99)-N/AByte:5-6Cargo Ambient Temperature(SPN169)-N/AByte:7Fuel Level2(SPN38)-N/A6.2.1.12DM1–Active Diagnostic Trouble CodesTransmission/ Reception Rate:Whenever a DTC becomes an active fault and at a normal update rate of one second or longer,and then becomes inactive,a DM1message will be transmitted to reﬂect this state change.If a different DTC changes state within one second update period,a new DM1message is transmitted to reﬂect this new DTC.Data Length:VariableData Page:0PDU Format:254PDU Speciﬁc:202Default Priority:6PGN:65226(0x00FECA)Byte:1Bits:8–7Malfunction Indicator Lamp Status(SPN1213)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:6–5Red Stop Lamp Status(SPN623)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:4–3Amber Warning Lamp Status(SPN624)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:2–1Protect Lamp Status(SPN987)–N/AByte:2Bits:8–1Reserved for SAE assignment Lamp Status Byte:3Bits:8–1SPN,8least signiﬁcant bits of SPN(SPN1214)(most signiﬁcant at bit8)Byte:4Bits:8–1SPN,second byte of SPN(most signiﬁcant at bit8)Byte:5Bits:8–6SPN,3most signiﬁcant bits(most signiﬁcant at bit8)Bits:5–1FMI(SPN1215)(most signiﬁcant at bit5)Byte:6Bit:8Bits:7–1SPN Conversion Method(SPN1706) Occurrence Count(SPN1216)Byte:7Bits:8–1Not Deﬁned Byte:8Bits:8–1Not Deﬁned6.2.1.13DM2–Previously Active Diagnostic Trouble CodesTransmission Rate:On RequestData Length:VariableData Page:0PDU Format:254PDU Speciﬁc:203Default Priority:6PGN:65227(0x00FECB)Byte:1Bits:8–7Malfunction Indicator Lamp Status(SPN1213)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:6–5Red Stop Lamp Status(SPN623)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:4–3Amber Warning Lamp Status(SPN624)00:Lamp Off01:Lamp On10:Error11:Not AvailableBits:2–1Protect Lamp Status(SPN987)–N/AByte:2Bits:8–1Reserved for SAE Assignment Lamp StatusByte:3Bits:8–1SPN,8least signiﬁcant bits of SPN(most signiﬁcant at bit8)(SPN1214)Byte:4Bits:8–1SPN,second byte of SPN(most signiﬁcant at bit8)(SPN1214)Byte:5Bits:8–6SPN,3most signiﬁcant bits(most signiﬁcant at bit8)(SPN1214)Bits:5–1FMI(most signiﬁcant at bit5)(SPN1215)Byte:6Bit:8SPN conversion Method(SPN1706)Bits:7–1Occurrence count(SPN1216)Byte:7Bits:8–1Not DeﬁnedByte:8Bits:8–1Not Deﬁned6.2.1.14DM3-Diagnostic Data Clear/Reset of Previously Active DTCsReception Rate:On Request using PGN59904Data Length:0Data Page:0PDU Format:254PDU Speciﬁc:204Default Priority:6PGN:65,228(0x00FECC)Note:All of the non-permanent diagnostic information pertaining to previously active(inactive) visible diagnostic trouble codes will be erased when this PG is requested.The diagnostic data associated with active trouble codes will not be affected.Upon reception of this PG request, DDEC10will respond with a Positive Acknowledgement(ACK).This message clears both CPC2+and MCM2previously active DTCs.6.2.1.15DM11—Diagnostic Data Clear/Reset for Active DTCsReception Rate:On Request Using PGN59904Data Length:0Data Page:0PDU Format:254PDU Speciﬁc:211Default Priority:6PGN:65,235(0x00FED3)Note:All of the non-permanent diagnostic information pertaining to active visible diagnostic trouble codes will be erased when this PG is requested.The diagnostic data associated with previously active(inactive)trouble codes will not be affected.Upon reception of this PG request,DDEC10will respond with a Positive Acknowledgement(ACK).This message clears both CPC2+and MCM2previously active DTCs.6.2.1.16DM13—Stop Start BroadcastReception Rate:As ReceivedData Length:8bytesData Page:0PDU format:223PDU speciﬁc:Destination AddressDefault priority:3PGN:57,008(0x00DF00)Byte:1SAE Primary LinksBits:8,7Current Data Link(SPN1230)00:Stop Broadcast01:Start Broadcast11:Don't Care00:Stop Broadcast01:Start Broadcast11:Don't CareBits:4,3J1922(SPN622)–N/ABits:2,1J1939Network#1,Primary Vehicle Network(SPN639)00:Stop Broadcast01:Start Broadcast11:Don't CareByte:2Other Networks#1Bits:8,7J1939Network#2-N/ABits:6,5ISO9141-N/ABits:4,3J1850-N/ABits:2,1Other,Manufacture Speciﬁed Port-N/AByte:3Other Networks#2Bits:8,7J1939Network#3-N/ABits:6–1Not DeﬁnedByte:4Control FlagsBits:8–5Hold Signal(SPN1236)0000:All Devices0001:Devices whose broadcast state has been modiﬁed0010–1110:Not Deﬁned1111:N/ABits:4–1Suspended Signal–N/AByte:5–6Suspended Duration–N/AByte:7–8SAE Reserved6.2.1.17EBC1–Electronic Brake Controller#1 Transmission/Reception Rate:100msData Length:8bytesData Page:0PDU format:240PDU speciﬁc:1Default priority:6PGN:61,441(0x00F001)Byte:1Status EBC1Bits:1-2ASR Brake Control Active–N/ABits:3-4Anti-Lock Braking(ABS)Active(SPN563)Bits:5-600:ABS Passive but installed 01:ABS Active10:Reserved11:Not AvailableBits:7-8EBS Brake Switch–N/AByte:2Brake Pedal Position–N/AByte:3Status EBC2Bits:1-2ABS Off-Road Switch–N/ABits:3-4ASR Off-Road Switch–N/ABits:5-6ASR“Hill Holder”Switch–N/ABits:7-8Traction Control Override Switch–N/A Byte:4Measured Aux.1Bits:1-2Accelerator Interlock Switch–N/ABits:3-4Engine Derate Switch–N/ABits:5-6Auxiliary Engine Shutdown Switch–N/ABits:7-8Remote Accelerator Enable Switch(SPN969)00:Off01:OnByte:5Engine Retarder Selection(SPN973)Resolution:0.4%/Bit,0%OffsetByte:6EBC Lamp Status–N/AByte:7Source Address of Controlling Device for Brake Control–N/A Byte:8Not Deﬁned6.2.1.18EBC2–Wheel Speed InformationReception Rate:100msData Length:8bytesData Page:0PDU format:254PDU speciﬁc:191Default priority:6PGN:65,215Bytes:1,2Front Axle Speed(SPN904)Resolution:1/256km/h per bit,0offset Byte:3Relative Speed,Front Axle,Left Wheel–N/A Byte:4Relative Speed,Front Axle,Right Wheel–N/A Byte:5Relative Speed,Front Axle#1,Left Wheel–N/A Byte:6Relative Speed,Front Axle#1,Right Wheel–N/A Byte:7Relative Speed,Front Axle#2,Left Wheel–N/A Byte:8Relative Speed,Front Axle#2,Right Wheel–N/A 6.2.1.19EC–Engine ConﬁgurationTransmission Rate:5sec.Data Length:34bytesData Page:0PDU format:254PDU speciﬁc:227Default priority:6PGN:65,251(0x00FEE3)Bytes:1,2Engine Speed At Idle,Point1(SPN188)Resolution:0.125rpm/Bit,0rpm offset Byte:3Percent Torque At Idle,Point1(SPN539)Resolution:1%/Bit,-125%offsetBytes:4,5Engine Speed At Point2(SPN528)Resolution:0.125rpm/Bit,0rpm offset Byte:6Percent Torque At Point2(SPN540)Resolution:1%/Bit,-125%offsetBytes:7,8Engine Speed At Point3(SPN529)Resolution:0.125rpm/Bit,0rpm offset Byte:9Percent Torque At Point3(SPN541)Resolution:1%/Bit,-125%offsetBytes:10,11Engine Speed At Point4(SPN530)Resolution:0.125rpm/Bit,0rpm offsetByte:12Percent Torque At Point4(SPN542)Resolution:1%/Bit,-125%offsetBytes:13,14Engine Speed At Point5(SPN531)Resolution:0.125rpm/Bit,0rpm offsetByte:15Percent Torque At Point5(SPN543)Resolution:1%/Bit,-125%offsetBytes:16,17Engine Speed At High Idle,Point6(SPN532)Resolution:0.125rpm/Bit,0rpm offsetBytes:18,19Engine Gain(KP)Of Endspeed Governor-N/ABytes:20,21Reference Engine Torque(SPN544)Resolution:1Nm/Bit,0Nm offsetByte:22,23Maximum Momentary Engine Override Speed,Point7(SPN533) Resolution:0.125rpm/Bit,0rpm offsetByte:24Maximum Momentary Engine Override Time Limit(SPN534) Resolution:0.1s/Bit,0s offsetByte:25Requested Speed Control Range Lower Limit-300RPM–N/A Byte:26Requested Speed Control Range Upper Limit–N/AByte:27Requested Torque Control Range Lower Limit–N/AByte:28Requested Torque Control Range Upper Limit–N/AByte29,30Extended Range Requested Speed Control Range Upper Limit —N/AByte31,32Engine Moment of Inertia(SPN1794)Resolution:0.004kgm2/Bit,0kgm2/Bit Offset Byte33,34Default Engine Torque Limit—N/A6.2.1.20EEC1–Electronic Engine Controller#1 Transmission Rate:10msData Length:8bytesData Page:0PDU format:240PDU speciﬁc:4Default priority:3PGN:61,444(0x00F004)Byte:1Status_EEC1Bits:8-5Not DeﬁnedBits:4-1Engine/Retarder Torque Mode(SPN899)0000:Low Idle Governor0001:Accelerator Pedal0010:Cruise Control0011:PTO Governor0100:Road Speed Governor0101:ASR Control0110:Transmission Control0111:ABS Control1000:Torque Limiting1001:High Speed Governor1010:Braking System1011:Remote Accelerator-N/A1100:Not Deﬁned1101:Not Deﬁned1110:Other1111:Not AvailableByte:2Drivers Demand Engine-Pct Torque(SPN512)Resolution:1%/Bit,-125%offsetByte:3Actual Engine-Percent Torque(SPN513)Resolution:1%/Bit,-125%offsetBytes:4,5Engine Speed(SPN190)Resolution:0.125rpm/Bit,0rpm offsetByte:6Source address of controlling device for engine control(SPN1483)Byte:7Bits:8–5Not DeﬁnedBits:1–4Engine Starter Mode(SPN1675)0000:Start Not Requested0001:Starter Active,Gear Not Engaged0010:Starter Active,Gear Engaged0011:Start Finished;Starter Not Active After Having Been ActivelyEngaged0100:Starter Inhibited Due To Engine Already Running0101:Starter Inhibited Due To Engine Not Ready For Start(preheating)0110:Starter Inhibited Due To Driveline Engaged Or OtherTransmission Inhibit0111:Starter Inhibited Due To Active Immobilizer1000:Starter Inhibited Due To Starter Over-Temp1001-1011:Reserved1100:Starter Inhibited-Reason Unknown1101:Error1110:Error1111:Not AvailableByte:8Engine Demand–Percent Torque(SPN2432)Resolution:1%/Bit,-125%offset6.2.1.21EEC2–Electronic Engine Controller#2 Transmission/Reception Rate:50msData Length:8bytesData Page:0PDU format:240PDU speciﬁc:3Default priority:3PGN:61,443(0x00F003)Byte:1Status_EEC2Bits:8-7Accelerator Pedal2Low Idle Switch—N/ABits:6-5Road Speed Limit Status(SPN1437)00:Active01:Not ActiveBits:4-3AP Kickdown Switch(SPN559)00:Kickdown Passive01:Kickdown Active11:Not ConﬁguredBits:2,1AP Low Idle Switch(SPN558)00:Not In Low Idle Condition01:In Low Idle Condition10:Error Detected11:Not ConﬁguredByte:2Accelerator Pedal Position(TPS)(SPN91)Resolution:0.4%/Bit,0%offsetByte:3Percent Load At Current Speed(SPN92)Resolution:1%/Bit,0%offsetByte:4Remote Accelerator(SPN974)Resolution:0.4%/Bit,0%offsetByte:5Accelerator Pedal Position2(SPN29)—N/AByte:6Vehicle Acceleration Rate Limit StatusBits:8–3Not DeﬁnedBits:2–1Vehicle Acceleration Limit Status(SPN2979)00:Limit Not Active01:Limit Active10:Reserved11:Not DeﬁnedByte:7Actual Maximum Available Engine percent Torque–(SPN3357) Byte:8Not Deﬁned6.2.1.22EEC3–Electronic Engine Controller#3Transmission Rate:250msData Length:8bytesData Page:0PDU format:254PDU speciﬁc:223Default priority:6PGN:65,247(0x00FEDF)Byte:1Nominal Friction-Percent Torque(SPN514)Resolution:1%/Bit,-125%OffsetBytes:2,3Engine's Desired Operating Speed(SPN515)Resolution:0.125rpm/Bit,0rpm OffsetByte4:Engine's Desired Operating Speed Asymmetry Adjustment(SPN519) Ratio:0to250Byte5:Engine Controlled Cooling Fan Losses–Percent Torque(SPN2978) Resolution:1%/Bit,-125%OffsetByte:6–7Exhaust Gas Mass(SPN3236)—N/AByte:8After-TreatmentBits:7-8After-Treatment Intake Dew Point Message–N/ABits:5-6After-Treatment Exhaust Dew Point Message–N/ABits:3-4After-Treatment Intake Dew Point Message–N/ABits:1-2After-Treatment Exhaust Dew Point Message–N/A 6.2.1.23EEC4–Electronic Engine Controller#4Transmission Rate:On RequestData Length:8bytesData Page:0PDU format:254PDU speciﬁc:190Default priority:7PGN:65,214(0x00FEBE)Bytes:1,2Rated Engine Power(SPN166)Resolution:0.5kW/Bit,0kW offset(0.67hp/Bit,0hp offset)Bytes:3,4Rated Engine Speed(SPN189)Resolution:0.125rpm/Bit,0rpm offset Bytes:5-8Not Deﬁned。

信息安全试题答案(题库)

题库一、选择1。

密码学的目的是(C)。

A。

研究数据加密 B. 研究数据解密C。

研究数据保密 D。

研究信息安全2。

从攻击方式区分攻击类型，可分为被动攻击和主动攻击.被动攻击难以(C），然而(C)这些攻击是可行的；主动攻击难以(C），然而(C)这些攻击是可行的.A. 阻止，检测,阻止,检测 B。

检测，阻止，检测,阻止C。

检测，阻止，阻止，检测 D. 上面3项都不是3。

数据保密性安全服务的基础是（D)。

A。

数据完整性机制 B。

数字签名机制C。

访问控制机制 D. 加密机制4。

数字签名要预先使用单向Hash函数进行处理的原因是（C）.A. 多一道加密工序使密文更难破译B。

提高密文的计算速度C。

缩小签名密文的长度,加快数字签名和验证签名的运算速度D。

保证密文能正确还原成明文5。

基于通信双方共同拥有的但是不为别人知道的秘密，利用计算机强大的计算能力，以该秘密作为加密和解密的密钥的认证是（C）.A. 公钥认证 B。

零知识认证C。

共享密钥认证 D。

口令认证6. 为了简化管理，通常对访问者（A)，以避免访问控制表过于庞大.A. 分类组织成组B. 严格限制数量C。

按访问时间排序，删除长期没有访问的用户D。

不作任何限制7. PKI管理对象不包括（A）。

A. ID和口令 B。

证书C。

密钥 D。

证书撤消8. 下面不属于PKI组成部分的是（D)。

A。

证书主体 B. 使用证书的应用和系统C。

证书权威机构 D。

AS9. IKE协商的第一阶段可以采用（C）。

A. 主模式、快速模式B. 快速模式、积极模式C. 主模式、积极模式D. 新组模式10．AH协议和ESP协议有（A）种工作模式。

A。

二 B. 三 C。

四 D。

五11. （C)属于Web中使用的安全协议。

A。

PEM、SSL B。

S-HTTP、S/MIMEC。

SSL、S-HTTP D. S/MIME、SSL12. 包过滤型防火墙原理上是基于(C）进行分析的技术。

A。

物理层 B。

Q.713 信令连接控制部分格式和编码

Signalling connection control part formats and codes
ITU-T Recommendation Q.713
(Formerly CCITT Recommendation)
ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 General Message transfer part (MTP) Signalling connection control part (SCCP) Telephone user part (TUP) ISDN supplementary services Data user part Signalling System No. 7 management ISDN user part Transaction capabilities application part Test specification Q3 INTERFACE DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) BROADBAND ISDN

SAP PI常用通道配置方法

常用通道创建方法目录常用通道创建方法 (1)1.SOAP协议Sender配置 (1)2.SOAP协议Receiver配置 (2)3.XI协议Sender配置 (2)4.XI协议Receiver配置 (3)5.FILE协议Sender配置 (4)6.FILE协议Receiver配置 (7)1.SOAP协议Sender配置1)Adapter Type 选择SOAP，下面选中Sender选项2)Transport Protocol、Message Protocol、Adapter Engine三项使用默认值3)HTTP Security Level选HTTP4)Quality of Service选项有Best Effort、Exactly Once、Exactly Once in Order，一般情况下同步选BE，异步选EO，如需要按顺序执行的选EOIO。

2.SOAP协议Receiver配置1)Adapter Type 选择SOAP，下面选中Receiver选项2)Transport Protocol、Message Protocol、Adapter Engine三项使用默认值3)Target URL写入目标服务URL地址3.XI协议Sender配置1)Adapter Type 选择XI，下面选中Sender选项2)Transport Protocol、Message Protocol、Adapter Engine三项使用默认值3)HTTP Security Level选HTTP4.XI协议Receiver配置1)Adapter Type 选择XI，下面选中Receiver选项2)Transport Protocol、Message Protocol、Adapter Engine三项使用默认值3)Addressing Type选URL Address,Target Host写入目标服务器的IP地址，Service Number写连接目标服务器的端口号，Path Prefix写目标服务路径4)Authentication Type选Use Logon Data for SAP System5)User Name写入登录上述服务器的用户名，User Password写入登录密码（两边要一致），Logon Language写入登录语言环境（要与proxy开发语言环境一致），Client写登录的客户端口号6)选中Transfer Hop List复选框5.FILE协议Sender配置1)Adapter Type 选择FILE，下面选中Sender选项2)Transport Protocol选File Transfer Protocol(FTP),Message Protocol选File ContentConversion,Adapter Engine使用默认值3)Source Directory 填要读取的文件目录4)File Name填文件名5)Server填文件所在服务器IP地址6)Port服务器端口7)Date Connection有Passive和Active两个选项，一般情况选Passive8)Connection Security选None就好了9)需要用户名登录时填入用户名和密码10)Connect Mode有Penmanently和Per File Transfer两个选项，这里选Penmanently11)Transfer Mode也有两个选项，Binary和txt12)Quality of Service三个选项，Best Effort、Exactly Once、Exactly Once in Order，文件多为异步，所以这里选EO13)Poll Interval读取文件的时间间隔，单位为秒14)Processing Mode三个选项，Archive、Delete、Test15)要存档时在Archive Directory里写入存档目录16)选中Add Time Stamp复选框可以存档的文件前面加上时间戳17)Empty-File Handling 也有三个选项Do not Create Message、Process Empty Files、Skip EmptyFiles18)File Type可以选Text和Binary，一般选TEXT19)File Encoding最好与服务的编码格式一致20)可以在服务器上写一些脚本，在处理文件前或者后执行，还可以限制脚本执行时间，执行超时则终止脚本21)内容转换参数设置将读取的文件内容输出到IR中配置的结构体，Document Name填IR中的Message Type Name,Document Namespace填该MT对应命名空间，Document Offset 设置读取文件时跳过的行数，Recordset Name填MT下结构体，Recorset Structure填文件内容要写入的结构，Recordset Sequence两个选项Variable,Ascending,可选择是否排序；Key Field Name可以设置一个关键字段（如果输出为一个结构体时可以不设置关键字段）；Key Field Type设置关键字段的类型，有四个选项，String(Case-Sensitive), String(Case-Insensitive), Integer,Float22)fieldNames设置文件内容与IR中各个字段的对应关系，例如BAT_HEAD.fieldNames,它的Value就是IR中配置的BAT_HEAD这个结构体里面的字段，按顺序写入，以逗号分隔；23)processFieldNames属性填fromConfiguration24)endSeparator设置每条记录的结尾分隔符，这里用的是回车符’nl’25)fieldSeparator设置每个字段值的分隔符26)keyFieldValue设置关键字的字段值27)Maximun File Size设置文件的最大值，单位是字节6.FILE协议Receiver配置1)Adapter Type 选择FILE，下面选中Receiver选项2)Transport Protocol选File Transfer Protocol(FTP),Message Protocol选File ContentConversion,Adapter Engine使用默认值3)Source Directory 填要写入的文件目录4)File Name填文件名，可以使用变量，图中使用了变量var1，具体在Advanced中定义5)Server填文件所在服务器IP地址6)Port服务器端口7)Date Connection有Passive和Active两个选项，一般情况选Passive8)Connection Security选None就好了9)需要用户名登录时填入用户名和密码10)Connect Mode有Penmanently和Per File Transfer两个选项，这里选Penmanently11)Transfer Mode也有两个选项，Binary和txt12)File Construction Mode有四个选项Create,Append,Add Time Stamp,Add Message Id13)可以选中复选框Overwrites Existing File覆盖同名的文件14)Put File 选Use Temporary File15)Empty-Message Handling设置空文件处理方式，Write 或Ignore16)Maximun Concurrency填117)File Type可以选Text和Binary,选Text时需在Content Conversion里设置相应属性18)Recordset Structure写入要写成文件的结构体名称19)可以对文件的写入作些控制，fieldSeparator字段分隔符；beginSpeparator每天记录的开始符；endSeparator每条记录的结束符；fieldFixedLengths每个字段的长度限制；fixedLengthTooShortHandling要写入的字段长度大于限制长度的处理方式有三种cut,error,Ignore;20)给变量指定值;21)可以IR映射中将指定的File Name带入文件头，在这里选中Use Adapter-Specific MessageAttributes和File Name复选框使用指定的文件名。

Protocol Test

hardware platform, three of which are available.A library of messages specified by IS-95A, -B, ARIB STD-T53 and IS-2000 is provided. (This is a subset of the complete library). Messages may also be modified and new messages can be added.One of the main applications of the CDMA-AIME system is to per-form CDG interoperability (stage 2) tests. A suite of test cases can be provided to enable this testing to be accomplished efficiently.T o enable the system to be used to its greatest potential, it has a Windows TM user interface that runs on a separate P C. There is an activity window to display status messages along with a Layer 2 /3 win-dow. A campaign manager is included to allow a series of test cases to be run sequentially.FULL SYSTEM DETAILS AND DATAForward Code ChannelsThe standard AIME supports transmission of up to 16 Forward Code Channels which can be any combination of:•Fundamental Code Channels•Supplemental Code Channels•Supplemental Channels•Paging Channels•Sync Channels•PilotsEach one of the 16 Code Channels is fully and independently pro-grammable and the following parameters are configurable by the user:•Frame rate•Long Code Mask•Frame Offset•Quick paging channels•Power control sub-channel state (where relevant)One or more of these channels can be used to provide an Orthogonal Channel Noise Source (OCNS) on an otherwise un-used Walsh code. FORWARD CDMA CHANNELSThe Forward Code Channels can be combined onto one or two Forward CDMA Channels. The user can program the properties of these Channels independently including:•PN offset•T otal Channel Output power•Individual code channel relative powers•Walsh Code of individual Code Channels•Propagation delayIn addition to these two Forward CDMA Channels, can also transmit another simplified Forward CDMA Channel that contains just a pilot and a random (non-OCNS) noise source. This is ideal for generat-ing a repeatable and accurately controllable level of noise for mobile testing where fading is not needed, for example in Pilot Pollution investigations. An EVDO upgrade also offers AWGN as an option.REVERSE CDMA CHANNELThe CDMA-AIME supports the reception of one or more Reverse CDMA Channels that can be:•Access Channel or•Reverse T raffic Channel consisting of a Fundamental Code Channel and up to 7 Supplemental Code Channels or up to 2 Supplemental Channels.HANDOFF CAPABILITYThe unit can support 2-way Soft Handoff, on any call type including medium speed data (MDR) calls with up to 7 Supplemental Code Channels.MULTIPLEX OPTION AND RADIO CONFIGURATION SUPPORT The system supports Multiplex Options 1 to 16 (Radio Configurations 1 to 5, one Fundamental and up to two Supplemental Channels or one Fundamental and up to 7 Supplemental Code Channels). Primary and Secondary traffic are also supported.The user specifies the Multiplex Option to be used in the script and this can then be changed dynamically during the call.In addition, the user can specify the transmission of various error conditions including:•Corrupted frame quality indicator•Corrupted frame bits after adding the frame quality indicator•Corrupted modulation symbols (after block interleaving)SERVICE OPTION SUPPORTThe unit supports most non-proprietary Service Options. Where data service options utilize application Layers above Air Interface Layer 3, standard commercial off-the-shelf (COTS) software is used where applicable.Summary of Service Options SupportedService Designated/Type of ServiceOptionNumber1 Basic Variable Rate Voice Service (8 kbps)2 Mobile Station Loop-back (8 kbps)3 Enhanced Variable Rate Voice Service (8kbps)4 Asynchronous Data Service (9.6 kbps)5 Group 3 Facsimile (9.6kbps)6 Short Message Services (Rate Set 1)7 Packet Data Service: Internet Protocol Stack only (Rate Set1)9 Mobile Station Loop-back (13 kbps)12 Asynchronous Data Service (14.4 or 9.6 kbps)13 Group 3 Facsimile (14.4 or 9.6 kbps)14 Short Message Services (Rate Set 2)15 Packet Data Service: Internet of ISO Protocol Stack (14.4kpbs)18 Over-the-air Parameter Administration (Rate set 1)19 Over-the-air Parameter Administration (Rate set 2)22 Medium Speed Packet Data Service: Internet Protocol only(RS1 forward, RS1 reverse)25 Medium Speed Packet Data Service: Internet Protocol only(RS2 forward, RS2 reverse)32 TDSO Test Data (RS1, RS2)33 144 kbps Packet Data35 Position Location (RS1)36 Position Location (RS2)54 IS-2000 Markov (RS1, RS2)55 IS-2000 Loopback (RS1, RS2)4100 Service Option 4, revision 14101 Service Option 5, revision 14103 Service Option 7, revision 132,768 High Rate Voice Service (13 kbps)32,798 Rate Set 1 Markov (8 k)32,799 Rate Set 2 Markov (13 k)Other options may be supplied if required.SYSTEM CONTROLThe CDMA-AIME System uses a COM compatible software inter-face, therefore the user can use the script interpreter built into the User Interface.SCRIPT LANGUAGEThe AIME uses an ActiveX scripting engine that allows SAX BASIC (Visual Basic) Script to be used to control the system. PROCEDURES AND TEST CASES SUPPLIEDThe standard system is supplied complete with a number of exam-ple-scripted procedures based on CDG Standards. These can be used directly or the user can incorporate them into other scripts. They can be freely copied and modified subject to licence. These pro-cedures include testing aspects of handoff, SMS, pilot pollution, power control, propagation delay, call setup, concurrent services etc..A facility is also provided to run a sequence of test cases as a test cam-paign. The user can vary the length and the content of the test cam-paign altering the parameters between successive runs to enable comprehensive test campaigns to be created.CONTROL OF EXTERNAL EQUIPMENTThe CDMA-AIME is capable of controlling additional external equip-ment (not supplied with the system), via the P C. Such equipment could include Multi-path Fading Simulators (Channel Simulators), or AWGN generators.Any standard PC interface can be used including GPIB, RS-232, and Ethernet and, as long as standard AP I interface driver software is available, the external equipment can be controlled from within the script.PROTOCOL TESTINGSignaling messages are completely controlled by the script. These can be the example scripts provided with the System, the User’s own scripts or the optional Conformance T est Cases available with the System.While the script is running, the system logs all signaling messages, on both Forward and Reverse links on the PC for future review.The user has full control of the protocols, procedures and timings used via the script. The user can send and receive any signaling mes-sages and parameters in those messages, including incorrect or erro-neous messages. The user can also construct new messages not yet in the IS-2000 message catalog.The timing of messages sent on the Forward Link can be set in 20 ms intervals relative to the reception of messages on the Reverse link, or relative to system time. All logged messages are also time stamped with the time they are sent or received by the 1X-AIME/1.The user can make the signaling procedures as simple or as complex as required for the type of testing to be performed.All the Message fields and their contents in eachmessage can be reviewed including the common identification fields where relevant.The messages can also be filtered to reduce the amount of informa-tion displayed. A “find” feature is included.RETRIEVABLE AND SETTABLE PARAMETERSThe Retrieve Parameters Message, Parameters Response Message and the Set Parameters Message are all fully supported and ID values of up to 65535 may be used to allow manufacturer - specific parame-ters to be investigatedFAX AND DATA TESTINGThe CDMA-AIME allows the user to perform functional tests of Fax and Data calls and data tranfer very simply and easily. All the neces-sary protocols are provided in the software supplied.For the very latest specifications visit FILTERING AND SEARCHINGAll messages can be ‘filtered’ so that only those of interest are dis-played in the window. In addition the ability to quickly search for a particular message or event in a saved file is also provided.HARDWARE OPTIONS6304 Test PlatformThe Racal Instruments Wireless Solutions 6304 is a cost effective protocol test platform for CDMA mobiles. It is designed for use in research and development environments or for use in laboratory con-formance and inter-operability testing.The unit acts as a single base station emulator, and provides built-in logging of signalling procedures to enable full testing and investiga-tion.The system is controlled by a PC to the required specification.Key features•Smallest and most inexpensive hardware platform option •Supports RIWS 1X-AIME software•Able to support soft handoff•Applications in development, regression testing, and conformance testing•Covers frequency band classes 0, 1, 3, and 46204 Test PlatformThe Racal Instruments Wireless Solutions 6204 CDMA platform is designed to enable testing of CDMA 1X and EV-DO mobiles and access terminals. The system provides an ideal platform to undertake development, conformance, interoperability, and regression testing.Key features•T ests cdmaOne (IS-95), CDMA2000 1X, and 1xEV-DO •Flexible hardware solution provides expandability for more com-plex testing scenarios•Dual cell emulation, to include handoff test scenarios •Wide variety of software options to provide comprehensive set of test facilities•Covers frequency band classes 0, 1, 3, and 4, with available hard-ware upgrade to cover band class 6The basic system consists of the 6204 Dual Rack Assembly containing two 6304s and RF combiner unit as well as all the necessary interconnection cablesThe system is connected to the Mobile-under-test via an RF antenna port using a coaxial cable. The RF input to the test system is protected, ensuring that even when interconnection errors are made the system will withstand any overload.6402 Test PlatformThe Racal Instruments Wireless Solutions 6402 CDMA test platform has been developed by Aeroflex and employs a Compact PCI (cPCI) architecture to provide a modular customizable design. This allows it to be configured and scaled for the user’s requirements. The unit is also able to provide complete coverage of the data rates used by CDMA2000 up to 3.1 Mbps and it has been designed with sufficient speed capability to ensure that it will be able to handle the higher data rates required in the future.A PC to the defined specification is also required to control the sys-tem. Control of the unit can either be achieved locally using an Ethernet connection, or remotely via a LAN.The unit is designed to be used with the Aeroflex CDMA software. The CDMA2000 1X software (Option 131) for Releases 0 and A is required as standard. Beyond this, further options can be added to suit the applications for the unit.The 6402 is available with a single or dual carrier capability. The sin-gle carrier option is able to simulate up to three cells on a single car-rier frequency enabling soft handoff to be tested. The dual carrier option provides the ability to simulate up to six cells on two carrier frequencies for testing 6-way soft and/or hard handoff.Key features•T ests CDMA2000 1X, 1xEV-DO and 1xEV-DV mobile stations •Flexible hardware solution provides expandability for more com-plex testing scenarios•Multi-cell emulation•Wide variety of software options to provide comprehensive set oftest facilitiesFor the very latest specifications visit TIMING MARKERSTiming signals provided1.25,2.5, 5, 20, 26.66 ms, 2 sec and a programmable marker Accuracy60 nsGENERALPOWER REQUIREMENTSVoltage range85-130 V and 180-264 VFrequency range47 to 66 HzPower consumption1000 Watts max (excluding PC)DIMENSIONS AND WEIGHTDimensions(WHD)562 mm x 526 mm x 420 mmWeight60 kg maxOPERATING TEMPERATURE10°C to 35°CHumidity5% to 85% RH (non-condensing)EMCComplies with EN61326-1 :1997+A1 : 1998 , Class A (emissions) , EN61326-1 :1997+A1 : 1998 Table 1 (immunity)SafetyComplies with EN61010-1: 20016204 PLATFORM SPECIFICATIONRF GENERATORFREQUENCYRange832 to 894 MHz805 to 1870 MHz930 to 1990 MHzRaster30 kHz or 50 kHzResolution<1 HzAccuracyAs frequency standardOUTPUT LEVELRangeRF In/Out Mobile Port: -50 to -100 dBm, -50 to -120 dBm (usable) RF Out port on 6303 may be used for output signal only:-20 to - 80 dBm, -20 to -100 dBm (usable)Resolution0.05 dBmSIGNAL QUALITY ρ>0.966ACCURACYTotal Output PowerRelative +1 dBAbsolute +5 dBCode Channel Power Relative+0.1 dBDynamic Range20 dBPORTSRF IN/OUT MOBILE PORTConnectorN type FemaleImpedance / Coupling50Ωnom / DCVSWR1.2:1Max / min Reverse power10 W RMS6304 RF OUT PORTConnectorTNC femaleImpedance / Coupling50 Ωnominal / DCVSWR1.2:1Max / Min Reverse power1 W RMSRF RECEIVERFREQUENCYRange824 to 849 MHz, 887 to 925 MHz, 1715 to 1780 MHz, 1850 to 1910 MHzTolerated frequency error±300 Hz (800 MHz band)± 150 Hz (1700 & 1900 MHz bands)Raster30 or 50 kHzResolutionCan be tuned to any receive channelFor the very latest specifications visit INPUT LEVELRangeRF Duplex Port +38 to -40 dBm MEASUREMENT ACCURACY (+38 to -20 dBm) Relative±0.4 dBAbsolute2.5 dBFREQUENCY STANDARDSEXTERNAL REFERENCE INPUTConnectorBNC femaleFrequency10 MHzLevel-2 to +19 dBmImpedance / Coupling50 Ωnom / ACREFERENCE OUTPUTAs reference inputLevel+9 dBmImpedance/ Coupling50 Ωnom / ACConnectorBNC femaleOutput protectionWill withstand a permanent short-circuitInternal overall stabilityFor one year ±0.12 ppm SYNCHRONIZATION PORTTiming signals provided20 ms frame clock26.67 ms clock80 ms clockEven second time mark 1.25 ms power control group clockSignal synchronized to the insertion of bad or deleted framesSignal synchronized to the start of power control bit sequences GENERALPOWER REQUIREMENTSVoltage range85-130 V and 180-246 VFrequency range45-66 HzPower consumption400 VA MAX (excluding PC)DIMENSIONS AND WEIGHTDimensions (6203 dual rack) (WHD)600 mm x 700 mm x 600 mmWeight60 kg approximatelyOperating temperature23ºC + 10ºCCDMA2000®is a registered trademark of the Telecommunications Industry Association (TIA-USA)cdmaOne TM is a registered trademark of the CDMA Development Group。

protocol总结

ONLINE = 1; //表示处于在线状态的用户
}
message UserInfo {
required int64 acctID = 1;
required string name = 2;
required UserStatus status = 3;
4. OFFLINE/ONLINE为枚举值。
5. 0和1表示枚举值所对应的实际整型值，和C/C++一样，可以为枚举值指定任意整型值，而无需总是从0开始定义。如：
enum OperationCode {
LOGON_REQ_CODE = 101;
LOGOUT_REQ_CODE = 102;
RETRIEVE_BUDDIES_REQ_CODE = 103;
LOGON_RESP_CODE = 1001;
LOGOUT_RESP_CODE = 1002;
三、定义第二个（含有枚举字段）Protocol Buffer消息。
//在定义Protocol Buffer的消息时，可以使用和C++/Java代码同样的方式添加注释。
enum UserStatus {
OFFLINE = 0; //表示处于离线状态的用户
}
这里将给出以上消息定义的关键性说明（仅包括上一小节中没有描述的）。
1. enum是枚举类型定义的关键字，等同于C++/Java中的enum。
2. UserStatus为枚举的名字。
3. 和C++/Java中的枚举不同的是，枚举值之间的分隔符是分号，而不是逗号。
}
数量。
5. required前缀表示该字段为必要字段，既在序列化和反序列化之前该字段必须已经被赋值。与此同时，在Protocol Buffer中还存在另外两个类似的关键字，optional和repeated，带有这两种限定符的消息字段则没有required字段这样的限制。相比于optional，repeated主要用于表示数组字段。具体的使用方式在后面的用例中均会一一列出。

国际化测试用例 testcase

国际化测试用例 testcase在进行软件开发过程中，国际化测试是非常重要的一环。

国际化测试的目的是确保软件在不同地区、不同语言环境下的正确运行和适应性。

本文将从不同角度介绍一些国际化测试用例。

1. 语言适配性测试在不同语言环境下，测试软件的显示、输入和输出是否正常。

检查软件界面是否能正确显示不同语言的字符和符号，输入框是否能够正确接受各种语言的输入，以及软件的输出是否能正确显示不同语言的结果。

2. 字符编码测试测试软件对不同字符编码的支持情况。

检查软件是否能正确处理各种字符编码，如UTF-8、GBK等。

测试包括输入、显示和存储等方面，确保软件能够正确处理不同字符编码的数据。

3. 日期和时间格式测试测试软件对不同日期和时间格式的支持情况。

检查软件在不同地区的日期和时间显示格式是否正确，以及软件是否能够正确处理不同日期和时间格式的输入和计算。

4. 货币格式和计算测试测试软件对不同货币格式和计算的支持情况。

检查软件在不同地区的货币符号和显示格式是否正确，以及软件是否能够进行正确的货币计算和格式化。

5. 时区测试测试软件对不同时区的支持情况。

检查软件在不同时区下的时间显示和计算是否正确，以及软件是否能够正确处理时区转换和夏令时等特殊情况。

6. 文化差异测试测试软件在不同地区文化差异下的适应性。

检查软件是否能够正确处理不同地区的文化习惯和约定，如日期和时间的书写顺序、姓名的排序规则等。

7. 错误信息本地化测试测试软件对错误信息的本地化支持情况。

检查软件是否能够根据不同语言环境显示相应的错误信息，以及错误信息是否能够准确传达给用户。

8. 安全性测试测试软件在不同语言环境下的安全性。

检查软件是否能够正确处理各种字符编码和特殊字符输入，以及是否能够防止跨站脚本攻击等安全漏洞。

9. 平台和设备兼容性测试测试软件在不同操作系统和设备上的兼容性。

检查软件在不同操作系统（如Windows、Mac、Linux等）和设备（如手机、平板、电脑等）上的显示和功能是否正常。

829-1998_IEEE Standard for Software Test Documentation

IEEE Std 829-1998(Revision ofIEEE Std 829-1983) IEEE Standard for Software Test DocumentationSponsorSoftware Engineering Technical Committeeof theIEEE Computer SocietyApproved 16 September 1998IEEE-SA Standards BoardAbstract: A set of basic software test documents is described. This standard speciÞes the form and content of individual test documents. It does not specify the required set of test documents. Keywords: test case specification, test design specification, test incident report, test item transmit-tal report, test log, test plan, test procedure specification, test summary reportIEEE Standards documents are developed within the IEEE Societies and the Standards Coordinat-ing Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an inter-est in participating in the development of the standard.Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is sub-jected to review at least every Þve years for revision or reafÞrmation. When a document is more than Þve years old and has not been reafÞrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reßect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership afÞliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments.Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to speciÞc applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards rep-resent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration.Comments on standards and requests for interpretations should be addressed to:Secretary, IEEE-SA Standards Board445 Hoes LaneP.O. Box 1331Piscataway, NJ 08855-1331USAAuthorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational class-room use can also be obtained through the Copyright Clearance Center.Introduction(This introduction is not part of IEEE Std 829-1998, IEEE Standard for Software Test Documentation.)PurposeThe purpose of this standard is to describe a set of basic software test documents. A standardized test docu-ment can facilitate communication by providing a common frame of reference (e.g., a customer and a supplier have the same deÞnition for a test plan). The content deÞnition of a standardized test document can serve as a completeness checklist for the associated testing process. A standardized set can also provide a baseline for the evaluation of current test documentation practices. In many organizations, the use of these documents signiÞcantly increases the manageability of testing. Increased manageability results from the greatly increased visibility of each phase of the testing process.This standard speciÞes the form and content of individual test documents. It does not specify the required set of test documents. It is assumed that the required set of test documents will be speciÞed when the standard is applied. Annex B contains an example of such a set speciÞcation.The readers of this standard are referred to Annex C for guidelines for using this standard to meet the requirements of IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information TechnologyÑSoftware life cycle processesÑLife cycle data.OverviewThe documents outlined in this standard cover test planning, test speciÞcation, and test reporting.The test plan prescribes the scope, approach, resources, and schedule of the testing activities. It identiÞes the items to be tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan.Test speciÞcation is covered by three document types:Ñ A test design speciÞcation reÞnes the test approach and identiÞes the features to be covered by the design and its associated tests. It also identiÞes the test cases and test procedures, if any, required to accomplish the testing and speciÞes the feature pass/fail criteria.Ñ A test case speciÞcation documents the actual values used for input along with the anticipated out-puts. A test case also identiÞes constraints on the test procedures resulting from use of that speciÞc test case. Test cases are separated from test designs to allow for use in more than one design and to allow for reuse in other situations.Ñ A test procedure speciÞcation identiÞes all steps required to operate the system and exercise the speciÞed test cases in order to implement the associated test design. Test procedures are separated from test design speciÞcations as they are intended to be followed step by step and should not have extraneous detail.Test reporting is covered by four document types:Ñ A test item transmittal report identiÞes the test items being transmitted for testing in the event that separate development and test groups are involved or in the event that a formal beginning of test exe-cution is desired.Ñ A test log is used by the test team to record what occurred during test execution.Ñ A test incident report describes any event that occurs during the test execution which requires further investigation.Ñ A test summary report summarizes the testing activities associated with one or more test design spec-iÞcations.Figure 1 shows the relationships of these documents to one another as they are developed and to the testing process they document.Figure 1ÑRelationship of test documents to testing processTerminologyThe words shall, must, and the imperative form identify the mandatory material within this standard. The words should and may identify optional material.AnnexesThe examples found in Annex A are meant to clarify the intent of the document descriptions found in the standard. Some suggestions about implementing and using the standard are in Annex B. Guidelines for compliance with IEEE/EIA 12207.1-1997 are provided in Annex C.AudienceThis standard should be of interest to software users and software procurement personnel; to development,test, and maintenance personnel; to operations and acquisition support managers; to software quality assur-ance personnel and auditors; and to participants in the legal system.ParticipantsThis revision was prepared by the Life Cycle Data Harmonization Working Group of the Software Engineer-ing Standards Committee of the IEEE Computer Society. At the time this standard was approved, the work-ing group consisted of the following members:Leonard L. Tripp, ChairThe following persons were on the balloting committee:Edward ByrnePaul R. CrollPerry DeWeeseRobin FralickMarilyn Ginsberg-FinnerJohn HarauzMark Henley Dennis Lawrence David Maibor Ray Milovanovic James Moore Timothy Niesen Dennis Rilling Terry Rout Richard Schmidt Norman F. Schneidewind David Schultz Basil Sherlund Peter V oldner Ronald WadeSyed AliH. Ronald BerlackRichard E. BiehlSandro BolognaJuris BorzovsAudrey C BrewerKathleen L. BriggsM. Scott BuckMichael CaldwellJames E. CardowJaya R. CarlEnrico A. CarraraLawrence CatchpoleKeith ChanAntonio M. CicuTheo ClarkeSylvain ClermontRosemary ColemanVirgil Lee CooperW. W. Geoff CozensPaul R. CrollPatricia W. DaggettGregory T. Daich Geoffrey Darnton Taz Daughtrey Bostjan K. Derganc Perry R. DeWeese Evelyn S. Dow Carl Einar Dragstedt Charles Droz Sherman Eagles Leo Egan Richard L. Evans William Eventoff Richard E. Fairley John W. Fendrich Jay Forster Kirby Fortenberry Eva Freund Richard C. Fries Roger U. Fujii David Gelperin Adel N. Ghannam Marilyn Ginsberg-Finner John Garth Glynn Julio Gonzalez-Sanz L. M. Gunther David A. Gustafson Jon D. Hagar John Harauz Herbert Hecht Debra Herrmann Umesh P. Hiriyannaiah John W. Horch Jerry Huller Peter L. Hung George Jackelen Frank V . Jorgensen Vladan V . Jovanovic William S. Junk George X. Kambic Ron S. Kenett Judith S. Kerner Robert J. Kierzyk Shaye Koenig Thomas M. Kurihara John B. Lane J. Dennis Lawrence Randal LeavittWhen the IEEE-SA Standards Board approved this standard on 16 September 1998, it had the following membership:Richard J. Holleman, Chair Donald N. Heirman, Vice ChairJudith Gorman, Secretary*Member EmeritusValerie E. ZelentyIEEE Standards Project EditorFang Ching LimWilliam M. LivelyJohn LordStan MageeDavid MaiborHarold MainsRobert A. MartinMike McAndrewPatrick D. McCraySue McGrathJacques MeekelJames Bret MichaelAlan MillerCelia H. ModellJames W. MoorePavol NavratMyrna L. OlsonIndradeb P. PalAlex PolackPeter T. PoonLawrence S. Przybylski Kenneth R. Ptack Ann E. Reedy Annette D. Reilly Terence P. Rout Andrew P. Sage Helmut Sandmayr Stephen R. Schach Hans Schaefer Norman Schneidewind David J. Schultz Lisa A. Selmon Robert W. Shillato David M. Siefert Carl A. Singer Nancy M. Smith Alfred R. Sorkowitz Donald W. Sova Luca Spotorno Julia Stesney Fred J. Strauss Christine Brown Strysik Sandra Swearingen Toru Takeshita Richard H. Thayer Booker Thomas Patricia Trellue Leonard L. Tripp Theodore J. Urbanowicz Glenn D. Venables Andre Villas-Boas Udo V oges Delores Wallace William M. Walsh John W. Walz Camille S. White-Partain Scott A. Whitmire P. A. Wolfgang Paul R. Work Natalie C. Yopconka Janusz Zalewski Geraldine Zimmerman Peter F. ZollSatish K. Aggarwal Clyde R. Camp James T. Carlo Gary R. Engmann Harold E. Epstein Jay Forster*Thomas F. Garrity Ruben D. GarzonJames H. GurneyJim D. IsaakLowell G. JohnsonRobert KennellyE. G. ÒAlÓ KienerJoseph L. KoepÞnger*Stephen R. LambertJim LogothetisDonald C. Loughry L. Bruce McClung Louis-Fran•ois Pau Ronald C. Petersen Gerald H. Peterson John B. Posey Gary S. Robinson Hans E. Weinrich Donald W. ZipseContents1.Scope (1)2.References (2)3.Definitions (2)4.Test plan (3)4.1Purpose (3)4.2Outline (3)5.Test design specification (6)5.1Purpose (6)5.2Outline (6)6.Test case specification (7)6.1Purpose (7)6.2Outline (7)7.Test procedure specification (9)7.1Purpose (9)7.2Outline (9)8.Test item transmittal report (10)8.1Purpose (10)8.2Outline (11)9.Test log (11)9.1Purpose (11)9.2Outline (12)10.Test incident report (13)10.1Purpose (13)10.2Outline (13)11.Test summary report (14)11.1 Purpose (14)11.2 Outline (14)Annex A (informative) Examples (16)Annex B(informative) Implementation and usage guidelines (40)Annex C(informative) Guidelines for compliance with IEEE/EIA 12207.1-1997 (41)IEEE Standard for Software Test Documentation1. ScopeThis standard describes a set of basic test documents that are associated with the dynamic aspects of soft-ware testing (i.e, the execution of procedures and code). The standard deÞnes the purpose, outline, and content of each basic document. While the documents described in the standard focus on dynamic testing, several of them may be applicable to other testing activities (e.g., the test plan and test incident report may be used for design and code reviews).This standard may be applied to commercial, scientiÞc, or military software that runs on any digital computer. Applicability is not restricted by the size, complexity, or criticality of the software. However, the standard does not specify any class of software to which it must be applied. The standard addresses the documentation of both initial development testing and the testing of subsequent software releases. For a particular software release, it may be applied to all phases of testing from module testing through user acceptance. However, since all of the basic test documents may not be useful in each test phase, the particu-lar documents to be used in a phase are not speciÞed. Each organization using the standard will need to spec-ify the classes of software to which it applies and the speciÞc documents required for a particular test phase. The standard does not call for speciÞc testing methodologies, approaches, techniques, facilities, or tools, and does not specify the documentation of their use. Additional test documentation may be required (e.g., code inspection checklists and reports). The standard also does not imply or impose speciÞc methodologies for documentation control, conÞguration management, or quality assurance. Additional documentation (e.g., a quality assurance plan) may be needed depending on the particular methodologies used.Within each standard document, the content of each section (i.e., the text that covers the designated topics) may be tailored to the particular application and the particular testing phase. In addition to tailoring content, additional documents may be added to the basic set, additional sections may be added to any document, and additional content may be added to any section. It may be useful to organize some of the sections into subsections. Some or all of the contents of a section may be contained in another document which is then referenced. Each organization using the standard should specify additional content requirements and conventions in order to reßect their own particular methodologies, approaches, facilities, and tools for test-ing, documentation control, conÞguration management, and quality assurance.This standard applies to documentation on electronic media as well as paper. Paper must be used for docu-ments requiring approval signatures, unless the electronic documentation system has a secure approval anno-tation mechanism and that mechanism is used.IEEEStd 829-1998IEEE ST ANDARD FOR 2. ReferencesThis standard shall be used in conjunction with the following publication.IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.13. DeÞnitionsThis clause contains key terms as they are used in this standard.3.1 design level: The design decomposition of the software item (e.g., system, subsystem, program, or module).3.2 pass/fail criteria: Decision rules used to determine whether a software item or a software feature passes or fails a test.3.3 software feature: A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).3.4 software item: Source code, object code, job control code, control data, or a collection of these items.3.5 test:(A) A set of one or more test cases, or (B) A set of one or more test procedures, or (C) A set of one or more test cases and procedures.3.6 test case speciÞcation: A document specifying inputs, predicted results, and a set of execution condi-tions for a test item.3.7 test design speciÞcation: A document specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.3.8 test incident report: A document reporting on any event that occurs during the testing process which requires investigation.3.9 testing: The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.3.10 test item: A software item which is an object of testing.3.11 test item transmittal report: A document identifying test items. It contains current status and location information.3.12 test log: A chronological record of relevant details about the execution of tests.3.13 test plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identiÞes test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.3.14 test procedure speciÞcation: A document specifying a sequence of actions for the execution of a test.3.15 test summary report: A document summarizing testing activities and results. It also contains an evalu-ation of the corresponding test items.1IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA (/).IEEE SOFTWARE TEST DOCUMENT A TION Std 829-1998 4. Test plan4.1 PurposeTo prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.4.2 OutlineA test plan shall have the following structure:a)Test plan identiÞer;b)Introduction;c)Test items;d)Features to be tested;e)Features not to be tested;f)Approach;g)Item pass/fail criteria;h)Suspension criteria and resumption requirements;i)Test deliverables;j)Testing tasks;k)Environmental needs;l)Responsibilities;m)StafÞng and training needs;n)Schedule;o)Risks and contingencies;p)Approvals.The sections shall be ordered in the speciÞed sequence. Additional sections may be included immediately prior to Approvals. If some or all of the content of a section is in another document, then a reference to that material may be listed in place of the corresponding content. The referenced material must be attached to the test plan or available to users of the plan.Details on the content of each section are contained in the following subclauses.4.2.1 Test plan identiÞerSpecify the unique identiÞer assigned to this test plan.4.2.2 IntroductionSummarize the software items and software features to be tested. The need for each item and its history may be included.References to the following documents, when they exist, are required in the highest level test plan:a)Project authorization;b)Project plan;c)Quality assurance plan;d)ConÞguration management plan;e)Relevant policies;f)Relevant standards.IEEEStd 829-1998IEEE ST ANDARD FOR In multilevel test plans, each lower-level plan must reference the next higher-level plan.4.2.3 Test itemsIdentify the test items including their version/revision level. Also specify characteristics of their transmittal media that impact hardware requirements or indicate the need for logical or physical transformations before testing can begin (e.g., programs must be transferred from tape to disk).Supply references to the following test item documentation, if it exists:a)Requirements speciÞcation;b)Design speciÞcation;c)Users guide;d)Operations guide;e)Installation guide.Reference any incident reports relating to the test items.Items that are to be speciÞcally excluded from testing may be identiÞed.4.2.4 Features to be testedIdentify all software features and combinations of software features to be tested. Identify the test design speciÞcation associated with each feature and each combination of features.4.2.5 Features not to be testedIdentify all features and signiÞcant combinations of features that will not be tested and the reasons.4.2.6 ApproachDescribe the overall approach to testing. For each major group of features or feature combinations, specify the approach that will ensure that these feature groups are adequately tested. Specify the major activities, techniques, and tools that are used to test the designated groups of features.The approach should be described in sufÞcient detail to permit identiÞcation of the major testing tasks and estimation of the time required to do each one.Specify the minimum degree of comprehensiveness desired. Identify the techniques that will be used to judge the comprehensiveness of the testing effort (e.g., determining which statements have been executed at least once). Specify any additional completion criteria (e.g., error frequency). The techniques to be used to trace requirements should be speciÞed.Identify signiÞcant constraints on testing such as test item availability, testing resource availability, and deadlines.4.2.7 Item pass/fail criteriaSpecify the criteria to be used to determine whether each test item has passed or failed testing.4.2.8 Suspension criteria and resumption requirementsSpecify the criteria used to suspend all or a portion of the testing activity on the test items associated with this plan. Specify the testing activities that must be repeated, when testing is resumed.IEEE SOFTWARE TEST DOCUMENT A TION Std 829-1998 4.2.9 Test deliverablesIdentify the deliverable documents. The following documents should be included:a)Test plan;b)Test design speciÞcations;c)Test case speciÞcations;d)Test procedure speciÞcations;e)Test item transmittal reports;f)Test logs;g)Test incident reports;h)Test summary reports.Test input data and test output data should be identiÞed as deliverables.Test tools (e.g., module drivers and stubs) may also be included.4.2.10 Testing tasksIdentify the set of tasks necessary to prepare for and perform testing. Identify all intertask dependencies and any special skills required.4.2.11 Environmental needsSpecify both the necessary and desired properties of the test environment. This speciÞcation should contain the physical characteristics of the facilities including the hardware, the communications and system soft-ware, the mode of usage (e.g., stand-alone), and any other software or supplies needed to support the test. Also specify the level of security that must be provided for the test facilities, system software, and propri-etary components such as software, data, and hardware.Identify special test tools needed. Identify any other testing needs (e.g., publications or ofÞce space). Iden-tify the source for all needs that are not currently available to the test group.4.2.12 ResponsibilitiesIdentify the groups responsible for managing, designing, preparing, executing, witnessing, checking, and resolving. In addition, identify the groups responsible for providing the test items identiÞed in 4.2.3 and the environmental needs identiÞed in 4.2.11.These groups may include the developers, testers, operations staff, user representatives, technical support staff, data administration staff, and quality support staff.4.2.13 StafÞng and training needsSpecify test stafÞng needs by skill level. Identify training options for providing necessary skills.4.2.14 ScheduleInclude test milestones identiÞed in the software project schedule as well as all item transmittal events.DeÞne any additional test milestones needed. Estimate the time required to do each testing task. Specify the schedule for each testing task and test milestone. For each testing resource (i.e., facilities, tools, and staff), specify its periods of use.IEEEStd 829-1998IEEE ST ANDARD FOR 4.2.15 Risks and contingenciesIdentify the high-risk assumptions of the test plan. Specify contingency plans for each (e.g., delayed delivery of test items might require increased night shift scheduling to meet the delivery date).4.2.16 ApprovalsSpecify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.5. Test design speciÞcation5.1 PurposeTo specify reÞnements of the test approach and to identify the features to be tested by this design and its associated tests.5.2 OutlineA test design speciÞcation shall have the following structure:a)Test design speciÞcation identiÞer;b)Features to be tested;c)Approach reÞnements;d)Test identiÞcation;e)Feature pass/fail criteria.The sections shall be ordered in the speciÞed sequence. Additional sections may be included at the end. If some or all of the content of a section is in another document, then a reference to that material may be listed in place of the corresponding content. The referenced material must be attached to the test design speciÞca-tion or available to users of the design speciÞcation.Details on the content of each section are contained in the following subclauses.5.2.1 Test design speciÞcation identiÞerSpecify the unique identiÞer assigned to this test design speciÞcation. Supply a reference to the associated test plan, if it exists.5.2.2 Features to be testedIdentify the test items and describe the features and combinations of features that are the object of this design speciÞcation. Other features may be exercised, but need not be identiÞed.For each feature or feature combination, a reference to its associated requirements in the item requirement speciÞcation or design description should be included.5.2.3 Approach reÞnementsSpecify reÞnements to the approach described in the test plan. Include speciÞc test techniques to be used. The method of analyzing test results should be identiÞed (e.g., comparator programs or visual inspection).IEEE SOFTWARE TEST DOCUMENT A TION Std 829-1998 Specify the results of any analysis that provides a rationale for test case selection. For example, one might specify conditions that permit a determination of error tolerance (e.g., those conditions that distinguish valid inputs from invalid inputs).Summarize the common attributes of any test cases. This may include input constraints that must be true for every input in the set of associated test cases, any shared environmental needs, any shared special procedural requirements, and any shared case dependencies.5.2.4 Test identiÞcationList the identiÞer and a brief description of each test case associated with this design. A particular test case may be identiÞed in more than one test design speciÞcation. List the identiÞer and a brief description of each procedure associated with this test design speciÞcation.5.2.5 Feature pass/fail criteriaSpecify the criteria to be used to determine whether the feature or feature combination has passed or failed.6. Test case speciÞcation6.1 PurposeTo deÞne a test case identiÞed by a test design speciÞcation.6.2 OutlineA test case speciÞcation shall have the following structure:a)Test case speciÞcation identiÞer;b)Test items;c)Input speciÞcations;d)Output speciÞcations;e)Environmental needs;f)Special procedural requirements;g)Intercase dependencies.The sections shall be ordered in the speciÞed sequence. Additional sections may be included at the end. If some or all of the content of a section is in another document, then a reference to that material may be listed in place of the corresponding content. The referenced material must be attached to the test case speciÞcation or available to users of the case speciÞcation.Since a test case may be referenced by several test design speciÞcations used by different groups over a long time period, enough speciÞc information must be included in the test case speciÞcation to permit reuse. Details on the content of each section are contained in the following subclauses.6.2.1 Test case speciÞcation identiÞerSpecify the unique identiÞer assigned to this test case speciÞcation.。

生产能力评估MCA

Does a formal and effective sub-tier supplier management process exist? (Delphi's requirements
management, requirements and evidence of the process for validating new suppliers and
Suggested Evidence for Compliance Verification对本列的建议证据
Score 1-3, * = N/A
G/Y/R
OBSERVATIONS THAT IMPACT SCORE影响得分的观察
Documentation and evidence of sub-tier
对于一个新项目的理解和文件证明,供货商用现有的EPS,对此提供的理解和其它答复，用
过去的文件也可以作为证明。
*
G
过程控制和作业计划表。有文件显示表明，除
了正常审核外，各级管理层都在各司其职，查
7
管理层能否保证用预防的/积极的方式进行跟踪和改进（如经常使用像前期预防和内部分级审查之类的重要工具）？是否明白和贯彻了？为了保证通常的失效模式在某些地方存在潜在的缺陷，管理层是否定期检讨 PFMEA，并不断改进？
state that Tier 1 suppliers are responsible for the
addressing quality concerns. Sub-tier
quality of the parts/ raw material from their sub-tier suppliers, including customer designated sources, and most questions in this assessment would apply to all sub-tier suppliers.) Does process include sub-tier communications to

Vector_ECU综合测试方案

测试概述基于CANoe的自动化测试系统
Test Spec.
Test-Environment
CANoe
GPIB, RS232 UDP, TCP
DAQ, IOcab, ...
CANcardXL, VN2600, ...
8 Test 9
Report
failed passed
Measurement & Test Hardware:
正确性：网络功能正确例如:发送报文的周期是否正确
测试工具
CANoe/CANoe.LIN+网络接口卡 Test Automation Editor(TAE)
©2009. HiRain Technologies. All rights reserved.
网络通信测试测试构架
HTML TTeesstt RReeppoorrtt
Word TTeesstt RReeppoorrtt
©2009. HiRain Technologies. All rights reserved.
测试报告 HTML测试报告
©2009. HiRain Technologies. All rights reserved.
©2009. HiRain Technologies. All rights reserved.
测试概述
测试内容
测试ECU的软件及硬件实现情况测试内容覆盖各个模块
©2009. HiRain Technologies. All rights reserved.
测试概述
测试的系统组成
……
被测单元 Under Test ECU/System
……
©2009. HiRain Technologies. All rights reserved.

protoc3默认值

protoc3默认值Google推出的Protocol Buffer是一种数据格式，可以用于数据的序列化和反序列化。

在HTTP2中，它被广泛用于数据通讯。

现在，随着protoc3的发布，有一个非常重要的更新：默认值。

下面，我们将一步一步地介绍这个更新：1.默认值是什么？在Protocol Buffer中，一个字段可以有一个默认值。

当一个消息中缺少某个字段时，就会使用默认值。

默认值可以是数字、字符串或者其他的数据类型。

这个概念在Protocol Buffer1和Protocol Buffer2中已经存在，但是在Protocol Buffer3中有所改变，因为现在支持更多的数据类型，比如JSON类型和枚举类型。

2.如何在Protoc3中定义默认值？在Protoc3中定义默认值可以使用等号。

比如：syntax = "proto3";message Test {string name = 1 [default = "unknown"];int32 age = 2 [default = 18];bool is_student = 3 [default = true];}在上面的例子中，我们定义了一个消息类型Test，有三个字段。

name的默认值是字符串"unknown"，age的默认值是整数18，is_student的默认值是布尔值true。

3.如何在Protoc3中读取默认值？当我们使用Protoc3来编码或者解码消息时，默认值的行为是不同的。

当编码一个消息时，如果字段的值等于默认值，这个字段将不会被编码。

当解码一个消息时，如果消息中没有某个字段，这个字段将被填充为它的默认值。

比如，我们编码一个Test消息，只有name字段被填充了，默认值被忽略：Test test;test.set_name("Tom");string encoded = test.SerializeAsString();当我们解码这个消息时，如果没有age和is_student字段，则它们将被填充为默认值：Test test;test.ParseFromString(encoded);cout << test.age() << endl; //18cout << test.is_student() << endl; //true4.默认值的优缺点默认值的好处在于，可以减小消息的大小，在通讯中降低带宽的消耗。

messages日志生成规则

在计算机科学领域中，日志文件是记录系统运行时所发生事件的重要手段之一。

在软件开发和系统管理中，通过对日志文件的分析可以快速定位问题并进行故障排查。

而在日志文件中，messages日志是其中一种常见的类型，它记录了系统的重要事件和警告信息。

确立合理的messages日志生成规则对于系统的稳定运行和故障排查具有重要意义。

二、 messages日志的概述messages日志是Linux系统中的一种日志类型，它记录了系统中的重要事件和警告信息。

这些事件和警告信息包括了系统启动、关机、用户登录、关键服务的启动和停止等。

messages日志是系统管理员和开发人员排查问题的重要依据，因此确保messages日志的准确和全面对于系统故障排查非常重要。

三、 messages日志生成规则的重要性1. 有利于问题排查和故障定位messages日志记录了系统中的重要事件和警告信息，通过分析messages日志，可以快速定位系统中的问题和故障。

如果日志生成规则不合理，会导致日志过于冗杂或者缺乏关键信息，给故障排查带2. 有助于系统性能优化合理的messages日志生成规则不仅可以帮助排查问题，还能够帮助系统管理员分析系统性能瓶颈，从而对系统进行优化。

3. 符合合规要求在一些行业和领域，对系统日志的要求较高，messages日志生成规则的合规性对于系统运行的合规合法非常重要。

四、 messages日志生成规则的具体内容1. 事件的级别（1）日志级别的划分messages日志中记录的事件可以根据重要程度分为不同的级别，常见的包括debug、info、warning、error等。

为了便于系统管理员和开发人员根据不同级别的事件快速定位和排查问题，需要合理划分和使用不同级别的日志。

（2）明确各级别事件的含义需要在规则中明确各级别事件的含义和应该记录的内容，以便于不同岗位的人员能够正确理解并处理日志。

2. 事件的格式（1）事件的时间格式在messages日志中，时间是非常重要的信息，可以帮助快速定位事件发生的时间和顺序。

消息鉴别码（MAC）相关国际标准介绍

消息鉴别码（MAC）相关国际标准介绍作者：谢宗晓董坤祥甄杰来源：《中国质量与标准导报》2021年第05期1 消息鉴别码消息鉴别码（Message Authentication Code，MAC）是一种确认完整性的技术。

MAC的输入，包括任意长度的消息和一个发行者和接收者的共享密钥。

MAC的输出，则是固定长度的字符串，这个数据串称为MAC值。

显然，输入和输出的方式，与杂凑函数很类似，但是，杂凑函数不需要密钥。

换句话说，MAC可以认为是与密钥相关的杂凑函数。

杂凑函数的最典型应用，例如存储用户口令，利用MD5 算法实现的口令的比对过程见图1。

类似于口令比对的方式，也可以检测消息传输过程中是否被篡改过，也就是说可以保证消息的“完整性”。

但是有时候我们需要确认消息是谁发送的，或者说需要对消息进行鉴别（authentication），不仅仅是判断完整性，这时候就需要MAC。

此时，共享密钥的作用就显现出来了。

例如，在银行转账业务中，收到的汇款请求指令，不仅要确保消息在传输过程中未被篡改，还要确保消息不是伪造的。

这正是MAC能够解决的问题，固定长度的字符串（类似于杂凑值）可以保证消息的完整性，共享的密钥可以实现一定程度的用户鉴别，即消息确实来自正确的发送者。

其工作原理见图2。

但是，从上述机制中也可以看到MAC本身是无法抗抵赖的，因为密钥是发送方和接收方共享的，实际上，抗抵赖性的实现一般要用数字签名技术[1]。

MAC还存在一个问题，就是密钥如何共享，这与对称密码算法的密钥分发问题是一致的。

2 MAC的实现MAC是一种机制，而不是某个单独的函数。

事实上，实现MAC的途径有很多，一般在实际应用中，主要是通过杂凑函数和分组密码，也可以通过序列密码和公钥密码等。

通过杂凑函数或分组密码实现MAC，是最常见的方式，对应的就是ISO/IEC 9797的3个部分，ISO/IEC 9797 总标题为：消息鉴别码（Message Authentication Codes，MACs），基本情况见表1。

短信网关接口协议(CMPP3.0)

中国移动通信企业标准QB-GF-028-2003中国移动通信互联网短信网关接口协议C h i n a M o b i l e P o i n t t o P o i n t版本号： 3.0.02003-11-03发布2003-11-03实施中国移动通信集团公司发布目录1 范围 (1)2 引用标准 (1)3 术语和定义 (1)4 网络结构 (3)5 CMPP功能概述 (3)6 协议栈 (4)7 通信方式 (4)7.1 长连接 (4)7.2 短连接 (6)7.3 本协议涉及的端口号 (6)7.4 交互过程中的应答方式 (7)8 消息定义 (7)8.1 基本数据类型 (7)8.2 消息结构 (7)8.3 消息头格式（Message Header） (8)8.4 业务提供商(SP)与互联网短信网关(ISMG)间的消息定义 (8)8.4.1 SP请求连接到ISMG（CMPP_CONNECT）操作 (8)8.4.1.1 CMPP_CONNECT消息定义（SP→ISMG） (8)8.4.1.2 CMPP_CONNECT_RESP消息定义（ISMG → SP） (9)8.4.2 SP或ISMG请求拆除连接（CMPP_TERMINA TE）操作 (9)8.4.2.1 CMPP_TERMINATE消息定义（SP→ISMG或ISMG → SP） (9)8.4.2.2 CMPP_TERMINATE_RESP消息定义（SP→ISMG或ISMG → SP） (10)8.4.3 SP向ISMG提交短信（CMPP_SUBMIT）操作 (10)8.4.3.1 CMPP_SUBMIT消息定义（SP→ISMG） (10)8.4.3.2 CMPP_SUBMIT_RESP消息定义（ISMG → SP） (11)8.4.4 SP向ISMG查询发送短信状态（CMPP_QUERY）操作 (12)8.4.4.1 CMPP_QUERY消息的定义（SP→ISMG） (12)8.4.4.2 CMPP_QUERY_RESP消息的定义（ISMG →SP） (13)8.4.5 ISMG向SP送交短信（CMPP_DELIVER）操作 (13)8.4.5.1 CMPP_DELIVER消息定义（ISMG→SP） (13)8.4.5.2 CMPP_DELIVER_RESP消息定义（SP → ISMG） (16)8.4.6 SP向ISMG发起删除短信（CMPP_CANCEL）操作 (16)8.4.6.1 CMPP_CANCEL消息定义（SP → ISMG） (16)8.4.6.2 CMPP_CANCEL_RESP消息定义（ISMG → SP） (17)8.4.7 链路检测（CMPP_ACTIVE_TEST）操作 (17)8.4.7.1 CMPP_ACTIVE_TEST定义（SP → ISMG或ISMG→SP） (17)8.4.7.2 CMPP_ACTIVE_TEST_RESP定义（SP → ISMG或ISMG→SP） (17)8.5 互联网短信网关(ISMG)之间的消息定义 (17)8.5.1 源ISMG请求连接到目的ISMG（CMPP_CONNECT）操作 (17)8.5.2 源ISMG请求拆除到目的ISMG的连接（CMPP_TERMINATE）操作 (17)8.5.3 链路检测（CMPP_ACTIVE_TEST）操作 (17)8.5.4 源ISMG向目的ISMG转发短信（CMPP_FWD）操作 (17)8.5.4.1 CMPP_FWD定义（ISMG→ ISMG） (18)8.5.4.2 CMPP_FWD_RESP定义（ISMG→ ISMG） (21)8.6 互联网短信网关(ISMG)与汇接网关(GNS)之间的消息定义 (21)8.6.1 ISMG请求连接到GNS或GNS请求连接到ISMG（CMPP_CONNECT）操作 (21)8.6.2 ISMG请求拆除到GNS的连接或GNS请求拆除到ISMG的连接（CMPP_TERMINA TE）操作218.6.3 ISMG向汇接网关查询MT路由（CMPP_MT_ROUTE）操作 (21)8.6.3.1 CMPP_MT_ROUTE消息定义（ISMG→GNS） (22)8.6.3.2 CMPP_MT_ROUTE_RESP消息定义（GNS → ISMG） (22)8.6.4 ISMG向汇接网关查询MO路由（CMPP_MO_ROUTE）操作 (22)8.6.4.1 CMPP_MO_ROUTE消息定义（ISMG→GNS） (22)8.6.4.2 CMPP_MO_ROUTE_RESP消息定义（GNS → ISMG） (23)8.6.5 ISMG向汇接网关获取MT路由（CMPP_GET_MT_ROUTE）操作 (23)8.6.5.1 CMPP_GET_MT_ROUTE消息定义（ISMG→GNS） (24)8.6.5.2 CMPP_GET_ ROUTE_RESP消息定义（GNS → ISMG） (24)8.6.6 SMG向汇接网关获取MO路由（CMPP_GET_MO_ROUTE）操作 (25)8.6.6.1 CMPP_GET_MO_ROUTE消息定义（ISMG→GNS） (25)8.6.6.2 CMPP_GET_MO_ROUTE_RESP消息定义（GNS → ISMG） (25)8.6.7 ISMG向汇接网关更新MT路由（CMPP_MT_ROUTE_UPDATE）操作 (26)8.6.7.1 CMPP_MT_ROUTE_UPDA TE消息定义（ISMG→GNS） (26)8.6.7.2 CMPP_MT_ROUTE_UPDA TE_RESP消息定义（GNS → ISMG） (27)8.6.8 ISMG向汇接网关更新MO路由（CMPP_MO_ROUTE_UPDATE）操作 (27)8.6.8.1 CMPP_MO_ROUTE_UPDATE消息定义（ISMG→GNS） (27)8.6.8.2 CMPP_MO_ROUTE_UPDATE_RESP消息定义（GNS → ISMG） (28)8.6.9 汇接网关向ISMG更新MT路由（CMPP_PUSH_MT_ROUTE_UPDA TE）操作 (29)8.6.9.1 CMPP_PUSH_MT_ROUTE_UPDATE消息定义（GNS→ISMG） (29)8.6.9.2 CMPP_PUSH_MT_ROUTE_UPDATE_RESP消息定义（ISMG → GNS） (29)8.6.10 汇接网关向ISMG更新MO路由（CMPP_PUSH_MO_ROUTE_UPDA TE）操作 (29)8.6.10.1 CMPP_PUSH_MO_ROUTE_UPDATE消息定义（GNS→ISMG） (30)8.6.10.2 CMPP_PUSH_MO_ROUTE_UPDATE_RESP消息定义（ISMG → GNS） (30)8.7 系统定义 (31)8.7.1 Command_Id定义 (31)8.7.2 错误码使用说明 (31)8.7.3 ISMG与GNS之间消息使用的错误码定义 (32)8.7.4 GNS上路由信息的Route_Id的编号规则 (33)9 附录1 短信群发功能的实现 (34)10 附录2 GNS协议目前实现说明 (34)11 附录3 全网SP和本地SP的服务代码的区别 (35)11.1 区别1：现网上全网SP和本地SP的服务代码的区别 (35)11.2 区别2：新分配的SP的服务代码规则 (35)12 修订历史 (36)前言本规范规定了移动梦网短信业务开展过程中各网元（包括ISMG、GNS和SP）之间的消息类型和定义。

DNP3通信协议测试软件

selectoperate模式指令序列自动被执行用于测试选择超时间隔或当从设备拒绝操作命令时作决定do输出点数16bitindex可以用于所有应用程序如果点数少于256个为了降低message包大小提高传输速率可选用8bitindex定义do置为on的时间只针对pontripclose而言ao输出测试点击protocolcommands上如图所示图标选择各个相应参数datawindow中看到的写下去的doao值设置扫描时间间隔点startrepeat测试软件按此时间间隔扫描设备上传下写的数据once同步一次
3
通讯测试
Integrity Poll 检测设备中上传的所有的事件数据（Class0123）
设置完毕点击Open打开Protocol Commands 对话框
例外报告支持( RBE)检测设备中上传变化了的事件数据（Class123），每隔一定时间收集次设备数据库中变化值，没有变化就不响应。
远端设备支持一个信息下多点的DO 控制操作，但所有点不必同时改变
定义DO置为ON的时间只针对pon trip close而言
AO输出测试
• 点击Protocol Commands上如图所示图标，选择各个相应参数
Data window中看到的写下去的DO、AO值
(3) 时间同步
• 设置扫描时间间隔，点Start Repeat 测试软件按此时间间隔扫描设备上传、下写的数据，once同步一次。
程序模块如下图所示
DO输出测试
• 点击Protocol Commands上右图图标，选择模式、控制代码等
sho模式： Select / Operate模式指令序自动被执行，用于测试选择超时间隔或当从设备拒绝操作命令时作决定
DO输出点数，16bitindex可以用于所有应用程序，如果点数少于256个为了降低message 包大小,提高传输速率可选用8bitindex

蓝牙协议一致性测试方案

测试蓝牙协议一致性测试方案1蓝牙协议概述蓝牙技术规范（Specification）包括协议（Protocol）和应用规范（Profile）两个部分。

协议定义了各功能元素（如串口仿真协议（RFCOMM）、逻辑链路控制和适配协议（L2CAP）等各自的工作方式，而应用规范则阐述了为了实现一个特定的应用模型（Usage model），各层协议间和运转协同机制。

显然，Protocol 是一种横向体系结构，而Profile是一种纵向体系结构。

较典型的Profile有拨号网络（Dial-up Networking）、耳机（Headset）、局域网访问（LAN Access）和文件传输（File Transfer）等，它们分别对应一种应用模型。

整个蓝牙协议体系结构可分为底层硬件模块、中间协议层（软件模块）和高端应用层三大部分。

图1中所示的链路管理层（LM）、基带层（BB）和射频层（RF）属于蓝牙的硬件模块。

RF层通过2.4GHz无需授权的ISM频段的微波，实现数据位流的过滤和传输，它主要定义了蓝牙收发器在此频带正常工作所满足的要求。

BB层负责跳频和蓝牙数据及信息帧的传输。

LM层负责连接的建立和拆除以及链路的安全机制。

它们为上层软件模块提供了不同的访问人口，但是两个蓝牙设备之间的消息和数据传递必须通过蓝牙主机控制器接口（HCI）的解释才能进行。

也就是说，HCI是蓝牙协议中软硬件之间的接口，它提供了一个调用下层BB、LM状态和控制寄存器等硬件的统一命令接口。

HCI层以上的协议实体运行在主机上，而HCI以下的功能由蓝牙设备来完成，二者之间通过一个对两端透明的传输层进行交互。

中间协议层包括逻辑链路控制和适配协议（L2CAP,Logical Link Control and Adaptation Protocol）、服务发现协议（SDP，Service Discovery Protocol）、串口仿真协议（RFCOMM）和电信通信协议（TCS,Telephone control Protocol）。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

1.mms protocol send request No. Subject 1 Content-Type--send request. 2 X-Mms-Message-Type 3 4 5 6 X-Mms-Transaction-ID X-Mms-MMS-Version Date From
Test case Content-Type--send request. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version Date From
Test case PDU type: connect Version(major) Version(minor) Capability length Client SDU Server SDU Protocal options Method mor Push mor Accept Accept-language Accept-charset User-agent profile PDU type: post URI length URI Headers length Content type
5 6
Subject Mms-Message-Class
Subject Optional. Mms-Message-Class
7 8 9
Mms-Message-Size Mms-Expiry
Mms-Message-Size Mms-Expiry
Mms-Content-Location Mms-Content-Location
9. wsp connect and get No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Subject PDU type: connect Version(major) Version(minor) Capability length Headers length Client SDU Server SDU Accept Accept-language Accept-charset User-agent profile PDU type:get URI length URI Test case PDU type: connect Version(major) Version(minor) Capability length Headers length Client SDU Server SDU Accept Accept-language Accept-charset User-agent profile PDU type:get URI length URI
12
X-Mms-DeliveryReport X-Mms-Read-Reply
X-Mms-Delivery-Report
13
X-Mms-Read-Reply
14
Content-Typenowledgement No. 1 2 3 4 Subject Test case X-Mms-Message-Type X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-Transaction-ID X-Mms-MMS-Version X-Mms-MMS-Version X-Mms-ReportX-Mms-Report-Allowed Allowed
Comments
Error-sending-address-unresolved = <Octet 132> Error-message-not-found = <Octet 133> Error-network-problem = <Octet 134> Error- content-not-accepted = <Octet 135> Error-unsupported-message = <Octet 136> Begin 0x93 6F6B=OK Begin 0x8B
X-Mms-Transaction-ID X-Mms-MMS-Version Message-ID Date From To Cc
Subject Subject X-Mms-Message-Class X-Mms-Message-Class
11
X-Mms-Priority
X-Mms-Priority
17
2.mms send confirmation No. 1 2 3 4 Subject Test case X-Mms-Message-Type X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-Transaction-ID X-Mms-MMS-Version X-Mms-MMS-Version X-Mms-ResponseStatus X-Mms-Response-Status
5
X-Mms-ReportAllowed
X-Mms-Report-Allowed
5. mms retrieve No. 1 Subject Test case X-Mms-Message-Type X-Mms-Message-Type
2 3 4 5 6 7 8 9 10
X-Mms-Transaction-ID X-Mms-MMS-Version Message-ID Date From To Cc
14
15
X-Mms-SenderVisibility
16
X-Mms-Sender-Visibility Optional. Default: show address/phone number of the sender to the recipient unless the sender has a number/address. X-Mms-Delivery-Report X-Mms-Delivery-Report Optional. Default determined when service is X-Mms-Read-Reply X-Mms-Read-Reply
4.mms notify response No. 1 2 3 4 Subject Test case X-Mms-Message-Type X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-Transaction-ID X-Mms-MMS-Version X-Mms-MMS-Version X-Mms-Status X-Mms-Status
Comments
No = <Octet 129> Begin 0x86 Yes = <Octet 128> No = <Octet 129> Begin 0x90 Yes = <Octet 128> No = <Octet 129>
Expected result Begin 0x8C m-send-conf = <Octet 129> Begin 0x98 Begin 0x8D VERSION:90 Begin 0x92 Ok = <Octet 128> Error-unspecified = <Octet 129> Error- service-denied = <Octet 130> Error-message-format-corrupt = <Octet 131>
Expected result MMS_CT_MULTI_MIXED=0X23(A3) (No SMIL) MMS_CT_MULTI_RELATED=0X33(B3)(With Begin 0x8C m-send-req = <Octet 128> Begin 0x98 Begin 0x8D Begin 0x85 Begin 0x89 length Address-present-token = <Octet 128> Insert-address-token = <Octet 129> Begin 0x97 Begin 0x82 Begin 0x81 Begin 0x96 Begin 0x8A Personal = <Octet 128> Advertisement = <Octet 129> Informational = <Octet 130> Auto = <Octet 131> Begin 0x88 Absolute-token = <Octet 128> Relative-token = <Octet 129> Begin 0x87 Absolute-token = <Octet 128> Relative-token = <Octet 129> Begin 0x8F Low = <Octet 128> Normal = <Octet 129> High = <Octet 130> Begin 0x94 Yes = <Octet 128>
7 8 9 10 11
To Cc Bcc Subject X-Mms-Message-Class
To Cc Bcc Subject X-Mms-Message-Class
12
X-Mms-Expiry
X-Mms-Expiry
13
X-Mms-Delivery-Time X-Mms-Delivery-Time Optional: default: X-Mms-Priority X-Mms-Priority Optional. Default: Normal.
7.mms deliver reporting No. 1 2 3 4 5 6 Subject Test case X-Mms-Message-Type X-Mms-Message-Type X-Mms-MMS-Version Message-ID To Date X-Mms-Status X-Mms-MMS-Version Message-ID To Date X-Mms-Status