This standard specifies a set of rules that must be followed when designing and technically reviewing EDIFACT messages and message components. It is intended to establish a consistent and objective basis for designing messages that comply with EDIFACT application-level syntax rules, version 1, 2, 3, and 4. Since dependency comments and repeated data are new concepts introduced in version 4 of the syntax rules, they are only applicable to messages designed to comply with version 4 of the syntax rules. GB/T 15947-2001 Rules for designing messages for electronic data interchange for administration, commerce, and transportation GB/T15947-2001 Standard download decompression password: www.bzxz.net

ICS.35.240.60
National Standard of the People's Republic of China
GB/T15947—2001
EDIFACT message design rules for EDIPublished on April 9, 2001
Implementation on October 1, 2001
National Quality and Technical Supervision Bureau
GB/T15947—2001
This standard is equivalent to the "Message Design Rules for Electronic Data Interchange in Administration, Commerce and Transport" (TRADE/CEFACT/1999/3) officially issued by the UN/EDIFACT Working Group (EWG) of the Centre for Simplification of Procedures and Practices in Administration, Commerce and Transport (CEFACT) of the United Nations Economic Commission for Europe.
This standard is a revision of GB/T15947-1995 "Guidelines and Rules for Message Design for Electronic Data Interchange in Administration, Commerce and Transport".
Compared with the previous version, this revised version has made the following major changes: 1) Introduced interactive EDI message design rules, and introduced rules for anti-collision technology, dependency annotation and duplication technology. 2) Adopted a segmented structure. The segmentation is carried out according to the hierarchical structure of the message. In order to facilitate further description of the rules of batch and interactive EDI, each segment is further subdivided into three subsections: rules common to batch and interactive EDI, rules applicable only to batch EDI, and rules applicable only to interactive EDI.
This standard is the first revision. The revised versions GB/T15947-2001 and GB/T15947-1995 are valid at the same time, and it is recommended to adopt the new version.
Appendix A, Appendix B, and Appendix E of this standard are standard appendices, and Appendix C and Appendix D are suggestive appendices. This standard is proposed by China Standards Research Center. This standard is under the jurisdiction of the National Technical Committee for Electronic Business Standardization. The drafting unit of this standard is China Standards Research Center. The main drafters of this standard are Wei Hong, Hu Hanjing, Liu Bisong, Cheng Nufan, Sun Wenfeng and Li Ying. I
1 Scope
National Standard of the People's Republic of China
Message design rules for electronic data interchange for administration, commerce and transportation
EDIFACT message design rules for EDI GB/T15947—2001
Replaces GB/T15947—1995
This standard specifies two sets of rules that must be followed in the design and technical review of EDIFACT messages and message components, aiming to establish a consistent and objective basis for the design of messages that comply with the 1st, 2nd, 3rd and 4th editions of the EDIFACT application-level syntax rules. Since dependency comments and repeated data elements are new concepts introduced in the 4th edition of the syntax rules, they are only applicable to the design of messages that comply with the 4th edition of the syntax rules. 2 Referenced standards
The clauses contained in the following standards constitute the clauses of this standard through reference in this standard. When this standard is published, the versions shown are valid. All standards will be revised, and parties using this standard should explore the possibility of using the latest versions of the following standards. GB/T1988-1998 Information technology information exchange - Seven-bit coded character set (eqVISO/IEC646:1991) GB/T14805-1993
3 Application-level syntax rules for electronic data interchange in administration, commerce and transport (idtISO9735:1988)
GB/T14805.1-1999
Application-level syntax rules for electronic data interchange in administration, commerce and transport (syntax version number: 4) Part 1: Common syntax rules and syntax service directory (idtISO9735-1:1998) GB/T1480 5.2—1999
9 Application-level syntax rules for electronic data interchange for administration, commerce and transport (Syntax version number: 4) Part 2: Syntax rules specific to batch electronic data interchange (idtISO9735-2:1998) GB/T14805.3—1999
9 Application-level syntax rules for electronic data interchange for administration, commerce and transport (Syntax version number: 4) Part 3: Syntax rules specific to interactive electronic data interchange (idtISO9735-3:1998) GB/T18391.5—2001
3 Definition
See Appendix A.
4 Message design rules
4.1 General
Information technology - Specification and standardization of data elements - Part 5, Principles for naming and identification of data elements (idtISo/IEC11179-5:1995)
4.1.1 Rules common to batch EDI and interactive EDI Rule 1: Designed messages, segments and data elements shall not include items marked with deletion in the EDIFACT directory. Rule 2: Designed segments and data elements shall not include items in the syntax service directory. Rule 3: Designed messages shall not include items in the syntax service directory, except for the message header (UNH/UIH), section control (UNS), anti-collision segment group header (UGH), anti-collision segment group trailer (UGT) and message trailer (UNT/UIT) service segments. Rule 4: Dependency annotations shall use valid dependency identifiers as specified in Appendix E. State Administration of Quality and Technical Supervision, approved on April 9, 2001, and implemented on October 1, 2001
4.2 Message
GB/T15947—2001
4.2.1 Common rules for batch EDI and interactive EDI Rule 5: The business function of a message (specified in the message definition) should not be repeated with the business function of another message in the target EDIFACT directory, and should not be expressed by the business function of another message in the target EDIFACT directory. Rule 6: Messages should be identified by a message type code. The code consists of 6 uppercase characters specified in GB/T1988 and is unique in the EDIFACT batch and interactive directories. Rule 7: The message name should be unique in the target EDIFACT directory. Rule 8: The message name should be consistent with the message definition. Rule 9: The message should start with the message header (UNT/UIT) service segment and end with the message trailer (UNT/UIT) service segment. Rule 10: The message structure shall be free of segment conflicts. Rule 11: UGH/UGT segment groups shall be used in the message specification when segment conflicts cannot be prevented by other means. In this case, UGH/UGT segment groups shall be used to encapsulate segment groups that cannot be unambiguously identified. Rule 12: In any case, the maximum number of repetitions of a UGH/UGT segment group is 1, and its status shall be the same as the status of the segment group it encapsulates.
Rule 13: In a UGH/UGT segment group, the UGH segment shall be the triggering segment. The UGT segment shall be the last segment in the segment group, its status shall be mandatory, and its maximum number of repetitions shall be 1. Rule 14: The purpose of each segment and segment group in the message shall be specified in the data segment description. Rule 15: The usage description of each segment in the data segment description shall be consistent with its segment definition in the EDIFACT segment directory. Rule 16, The usage description of each segment and segment group in the data segment description shall be consistent with its status and maximum number of repetitions defined in the segment table.
Rule 17: The structure of the segment table should be consistent with the message definition and data segment description. Rule 18: The segments or segment groups specified in the segment table should have a mandatory or conditional status. Rule 19: The segments or segment groups specified in the segment table should have a maximum number of repetitions. Rule 20: Mandatory segments or segment groups should not involve dependency comments. Rule 21: Dependency comments specified for the same segment or segment group should not conflict. Rule 22: The dependency comment should list the location identifiers of at least two different segment groups, or a segment group and a segment, or two different segments.
Rule 23: The dependency comment list should only list the location identifiers of segments or segment groups in the same level and the same parent structure (message or segment group).
4.2.2 Rules specific to Batch EDI
Rule 24: There should be at least one segment between the UNH service segment and the UNT service segment, and this segment cannot be the BGM or UNS service segment. Rule 25: The BGM segment should be the first non-service segment. It should be an independent segment with a mandatory status and a maximum repetition count of 1.
4.2.3 Rules specific to Interactive EDI
Rule 26: There should be at least one segment between the UIH service segment and the UIT service segment, and this segment cannot be the BGM or UNS service segment. 4.3 Segmented Messages
4.3.1 Rules common to batch EDI and interactive EDI Rule 27: The section control (UNS) service segment is used only to prevent segment conflicts between segments in one section and segments in the next section of the message. It separates each section in a segmented message, has a mandatory status, a maximum number of repetitions of 1, and appears as an independent segment at the beginning of the detail section and/or summary section.
Rule 28: Each section of a segmented message shall be identified in the data segment description and segment table. A segmented message consists of one of the following: 2
A header section and a detail section;
A header section, a detail section and a summary section;
A detail section and a summary section.
4.4 Segment Groups
GB/T15947—2001
4.4.1 Rules common to batch EDI and interactive EDI Rule 29: A segment group shall start with a trigger segment. Rule 30: The trigger segment shall have a mandatory status. Rule 31: The maximum number of repetitions of a trigger segment is 1. Rule 32: In addition to the trigger segment, a segment group should include at least one other segment or segment group. 4.5 Segments
4.5.1 Rules common to batch EDI and interactive EDI Rule 33: Segments should be identified by segment tags. Segment tags consist of 3 uppercase characters as specified in GB/T1988. The segment tag of a user segment should not start with the letter "U".
Rule 34: Segment tags should be unique in the EDIFACT batch and interactive segment directories. Rule 35: Segment definitions shall:
- describe the purpose of the segment;
- be consistent with the definitions of the data elements therein;
- not contain the definitions of the data elements therein;
- be unique in the target EDIFACT segment directory;
- give the full name of the acronym at the first occurrence;
- not contain abbreviations;
- not contain gender bias;
- not contain the phrase "no explanation required" "to be defined" "to be provided" or its synonyms unless the phrase is an inherent part of the segment definition. Rule 36: Segment names shall be unique in the target EDIFACT segment directory. Rule 37: Segment names shall be consistent with segment definitions. Rule 38: The purpose of a segment shall not duplicate the purpose of another segment at the same level of abstraction in the target EDIFACT segment directory and shall not be expressed by the purpose of another segment at the same level of abstraction in the target EDIFACT segment directory. Rule 39: The data elements in a segment shall be directly related to the purpose of the segment. Rule 40: Data elements in a segment shall have a mandatory or conditional status. Rule 41: For all data elements following a qualifier data element in a segment, mandatory data elements shall be listed first, followed by conditional data elements.
Rule 42: When adding a data element to an existing segment, the data element shall be given a conditional status and placed at the end of the segment. Rule 43: An independent data element in a segment structure may be replaced by a composite data element only if all of the following conditions are met: - the first component data element of the composite data element is the independent data element and has the same status or conditional status as the independent data element;
- the status of the composite data element is the same as the status of its first component data element; - all other component data elements have conditional status. Rule 44: When a data element is deleted from an existing segment, the segment shall be marked for deletion in the target EDIFACT segment directory. Rule 45: When the status of a data element in an existing segment is changed from conditional to mandatory, the segment shall be marked for deletion in the target EDIFACT segment directory.
Rule 46: Data elements in a segment shall have a maximum number of repetitions. Rule 47: Mandatory data elements shall not involve dependency annotations. Rule 48: Dependency annotations specified for the same data element shall not conflict. 3
GB/T159472001
Rule 49: Dependency annotations shall list at least two different data element position identifiers. Rule 50: Dependency annotations shall only list position identifiers contained in the segment to which the dependency annotation refers. Rule 51: Dependency annotations shall only be used to express the relationship between the following data elements in a segment: independent data elements and independent data elements;
a composite data element and a composite data element;
an independent data element and a composite data element.
4.5.2 Rules specific to Batch EDI
Rule 52: A segment shall not include the entire contents of another segment. Rule 53: A segment shall specify a qualifier data element as the first data element in the segment immediately following the segment marker. Rule 54: In addition to the qualifier data element that qualifies the segment, a segment shall contain at least one more data element. Rule 55: The same data element shall not appear in more than one position in a segment. Rule 56: Only qualifier composite data elements or composite data elements containing data elements 1131 (code table qualifier)/3055 (code table responsible organization, code type) can be repeated data elements. Rule 57: The maximum number of repetitions of a qualifier composite data element shall be less than or equal to the number of code values ​​specified by the qualifier data element in the composite data element.
4.5.3 Rules Specific to Interactive EDI
Rule 58: A segment shall not contain the entire contents of another segment in the interactive segment directory. Rule 59: A segment shall contain at least one data element that is not a qualifier data element. Rule 60: When a segment is not a qualifier segment, the mandatory data elements shall be listed first, followed by the conditional data elements. Rule 61: In a segment that needs to be qualified, the qualifier data element shall be the first data element of the segment. Rule 62: The segment qualifier shall not be a repeating data element. 4.6 Composite Data Elements
4.6.1 Rules Common to Batch EDI and Interactive EDI Rule 63: A composite data element definition shall:
- describe the meaning of the composite data element;
state what the composite data element is, not just what it is not;
be consistent with the data element definition contained in it;
not contain the data element definition contained in it;
be unique in the target EDIFACT composite data element directory;
state it in singular form;
give the full name of the acronym at its first occurrence;
not contain abbreviations;
not contain gender bias;
not contain the phrase "no explanation required, "to be defined, "to be provided" or its synonyms , unless the phrase is an inherent part of the composite data element definition.
Rule 64: Composite data element names shall be unique within the target EDIFACT composite data element directory. Rule 65: Composite data element names shall be consistent with composite data element definitions. Rule 66: Data element names in a simple data element pair shall have the same object class terms and property terms. Coded simple data elements shall have the representation term "code" or the representation term "identifier". Non-coded simple data elements shall have the representation term "description" or the representation term "name". Rule 67: Data element definitions in a simple data element pair shall be identical except for the subject term. The definition of a coded simple data element shall be "code for...". For non-coded simple data elements, if its representation term is "description" If the expression word is "name", its definition should be "the name of ...". Rule 68: Component data elements should have mandatory or conditional status. 4
GB/T15947—2001
Rule 69: Component data elements should not be repeated data elements. Rule 70: In the current composite data element, when the status of a component data element changes from conditional to mandatory, the composite data element should be marked with a deletion mark in the target EDFACT composite data element directory. Rule 71: If the structure of a composite data element consists of only a code-type simple data element and the simple data elements 1131 and 3055 that follow it, the status of the code-type simple data element should be mandatory. Rule 72: When adding a simple data element to an existing composite data element, it should be given a conditional status and placed at the end of the composite data element.
Rule 73: When deleting a component data element from an existing composite data element, the composite data element should be marked as deleted in the self-standard EDIFACT composite data element directory.
Rule 74: Dependency comments should only involve component data elements with conditional status. Rule 75: Dependency comments specified for the same component data element should not conflict. Rule 76: Dependency comments should list the position identifiers of at least two different component data elements. Rule 77: Dependency comments should only list the position identifiers contained in the composite data element to which the dependency comment refers. 4.6.2 Rules Specific to Batch EDI
Rule 78: A composite data element shall be specified when any of the following is required: to reference an external code table (using simple data elements 1131 and 3055); to combine a simple data element into a simple data element pair: to further qualify a simple data element (a qualifier data element of a qualifier segment cannot satisfy this qualification requirement); to qualify a simple data element pair.
Rule 79: The composite data element name shall have the same object classifier and property terms as the coded and/or non-coded simple data elements (except simple data elements 1131 and 3055) specified in the composite data element structure. Rule 80: A qualifier data element in a composite data element shall have mandatory status. Rule 81: Composite data elements should have one of the following structures: Structure 1:
Coded data element
Non-coded data element
Structure 2:
Coded data element
Structure 3:
Coded data element
Non-coded data element
Structure 4:
Qualifier data element
Coded data element
Structure 5:
Qualifier data element
Non-coded data element
Structure 6:
Qualifier data element
See Note 1
See Note 1
See Note 1
See Note 1
Coded data element
Non-coded data element
Structure 7:
Qualifier data element
Coded data element
Structure 8:
Qualifier data element
Coded data element
Non-coded data element
See Note 1
See Note 1
See Note 1
See Note 1
Note 1 This data element is part of a simple data element pair. 4.6.3 Rules specific to interactive EDI
GB/T15947—2001
Rule 82: A composite data element should be specified when one of the following requirements is met: reference to external code tables (using simple data elements 1131 and 3055); a simple data element is combined into a simple data element pair; a simple data element is further qualified (the qualifier data element of the qualified segment cannot meet the qualification requirements); a simple data element pair is qualified;
a group represents data for a single business purpose. Rule 83: The composite data element name should be consistent with the composite data element definition. Rule 84: A composite data element should not only include the entire content of another composite data element in the interactive composite data element directory. Rule 85: In a composite data element that needs to be qualified, the qualifier data element should be the first component data element in the composite data element. Rule 86: In a qualified composite data element, the mandatory simple data element should follow the qualifier data element of the composite data element. In an unqualified composite data element, the mandatory simple data element should be placed first. Rule 87: The qualifier of a component data element shall immediately follow the component data element it qualifies. 4.7 Simple Data Elements
4.7.1 Rules Common to Batch and Interactive EDI Rule 88: A simple data element definition shall:
describe the meaning of the simple data element;
- state what the simple data element is, not just what it is not; be unique in the target EDIFACT data element directory;
describe it in the singular;
give the full name of the acronym at the first occurrence;
- not include abbreviations;
- not include gender preferences;
not include the phrase "no explanation required", "to be defined", "to be provided", or its synonyms, unless the phrase is an inherent part of the data element definition. Rule 89: A simple data element name shall be unique in the target EDIFACT data element directory. Rule 90: A simple data element name shall be consistent with the simple data element definition. Rule 91: The name of a coded simple data element that is not defined as a qualifier data element shall end with the word "code" or the word "identifier".
Rule 92: A simple data element shall specify its data value representation. 6
GB/T15947—2001
Rule 93: The data value representation of a coded simple data element listed in the EDIFACT code table shall be at least an..3. 4.8 External code table
4.8.1 Rules common to batch EDI and interactive EDI (none)
4.8.2 Rules specific to batch EDI
Rule 94: The identification of the external code table shall be obtained by using simple data elements 1131 and 3055 in a composite data element. Rule 95: A coded independent data element or a coded component data element that is not directly followed by component data elements 1131 and 3055 shall have at least one code value assigned to it in the EDIFACT code table (except for UNECE approved recommendations or identified ISO code tables).
4.8.3 Rules specific to interactive EDI
4.9 Code Values
4.9.1 Rules common to batch EDI and interactive EDI Rule 96: Code value names and code value definitions shall not exceed the scope of the simple data element names and simple data element definitions to which they belong. Rule 97: Code value definitions shall:
be unique in the code table of the simple data element to which they belong; -be described in the singular;
-describe what the code value represents;
-give the full name of the acronym the first time it appears; -not contain abbreviations;
-do not include the phrase "no explanation required", "to be defined", "to be provided" or its synonyms, unless the phrase is an inherent part of the code value definition. Rule 98: Code value names shall be consistent with code value definitions. Rule 99: Code values ​​for qualifier data elements shall be specified only in the EDIFACT code table. 7
A1 Batch EDIbatchEDI
GB/T15947—2001
Appendix A
(Normative Appendix)
An electronic data exchange between parties that does not have a strong requirement for interactive, formalized data exchange in the form of queries and responses.
2Characteristiccharacteristic
The characteristic or quality of an object.
Codelistcodelist
The complete set of data element values ​​for a coded simple data element. A4CodelistdirectoryA list of identified and specified code lists. A5
Codevaluecodevalue
The coded representation of an allowed data element value. CodevaluedefinitioncodevaluedefinitionThe description of the meaning of a code value and distinguishes it from all other code values ​​in the code list. Also called "codevalue description" in document R:1023.
A7ComponentdataelementcomponentdataelementA simple data element used in a composite data element. A8
CompositedataelementA collection of identified, named and structured, functionally related component data elements that are specified in a composite data element specification. It represents a single unit of data. In addition, in interactive EDI transactions, it can represent a single business purpose. Composite data element definition compositedataelementdefinition describes the meaning of a composite data element and distinguishes it from all other composite data elements. In file R.Also called "composite data element description" in 1023.
compositedata elementdirectoryA10Composite data element directory
A list of identified and named composite data elements and their specifications. A11
Composite data element specificationcompositedataelementspecificationA description of the composite data element in the composite data element directory, which includes a description of the location, status and dependency annotations of each component data element that constitutes the composite data element. Conditional
A status type used in a message specification, segment specification or composite data element specification to indicate that a segment group, segment, composite data element, independent data element or component data element is optional or is only used when a condition is met. Data elementdataelement
A data unit described in a data element specification. There are two types of data elements: simple data elements and composite data elements. Data element definitiondataelementdefinitionA14
Description of the meaning of a simple data element (simple data element definition) or a composite data element (composite data element definition). Data element directorydataelementdirectoryA15
A list of simple data elements (simple data element directory) or a list of composite data elements (composite data element directory) that have been identified, named and specified.
data elementspecification
Data element specification
GB/T15947—2001
A description of a composite data element in a composite data element directory (composite data element specification) or a description of a simple data element in a simple data element directory (simple data element specification).
Simple data element valuesimpledataelementvalueA17
A specific instance of a simple data element, which shall be represented as specified in the simple data element specification, and when it is of code type, shall be represented as specified in the code table.
A18data segment declarationsectionA section in a message specification that defines the usage of each segment and segment group in a message.data value representationdata value representationA19
The allowed character types (e.g., letters, numbers) and length conditions associated with the data element value of a simple data element.A20
dependency identifierdependency identifierAn identifier used in a dependency note to specify the dependency type between items in a dependency note.A21
dependency notedependency note
A note used to: (1) express the relationship between segments, between segment groups, or between segments and segment groups in a message specification; (2) express the relationship between data elements in a segment specification; (3) express the relationship between component data elements in a composite data element specification.dialoguedialogue
A two-way conversation between an initiator and a responder in an interactive EDI transaction, usually consisting of a pair of exchanges. A23
Explicit qualificationexplicitqualification provides a specific meaning to a simple data element by using it in conjunction with a qualifier data element. A24
External code listexternalcodelist
A list of code values ​​outside the EDIFACT code list that is maintained and published by a recognized maintenance organization. A25
Identifieridentifier
A character or group of characters used to identify or name a data item and possibly indicate a certain property of the data item. A263bzxz.net
Interactive EDI-EDI
Predefined and structured data exchange carried out in an ad hoc manner in a dialogue between a pair of collaborating processes for some business purpose, which follows the grammatical rules of GB/T 14805.1 and GB/T 14805.3. Interactive EDI transactionI-EDItransactionA27
An application instance of a script, consisting of one or more dialogues. A28
implicit qualification implicit qualification provides a specific meaning to a simple data element by the functional definition of the interactive message type, interactive segment type and/or composite data element type to which it belongs or by its position in an interactive segment or interactive composite data element. level of abstraction
A degree of generalization of broad or common characteristics from narrow or specific characteristics. A30
mandatory
A type of status used in message specifications, segment specifications and composite data element specifications to specify that a segment group, segment, composite data element, independent data element or component data element shall be used at least once. maximum number of occurrences A31
The maximum number of times an item may appear at a certain position in a message or its components. A32 message
An identified, named and structured set of functionally related segments that covers the requirements of a particular transaction type (such as an invoice) and is described in a message specification. A message begins with a message header and ends with a message trailer. In transmission, a message is a specific, ordered collection of segments that follow the message specification. Message definition messagedefinition
A section in a message specification that describes the function of a message and makes it different from all other messages. In file R.In 1023, 9
is called "functional definition".
Message directorymessagedirectory
GB/T15947—2001
A list of identified and named messages and message specifications. A35Message headermessageheader
Starts and uniquely identifies the service segment of the message. Message specificationmessagespecificationA36
Description of the message in the message directory, which includes the location, status, maximum number of repetitions and attribute annotations of each segment and segment group that make up the message.
Message trailermessagetrailer
Ends the service segment of the message.
Message typemessagetype
A code that identifies the message type.
objectclasstermobjectclassterm
The first component of the name of a simple data element, composite data element, or segment, which indicates the dominant aspect of the name.positionidentifierpositionidentifierA40
An identifier used in a dependent annotation to identify the position of an item (segment group, segment, or data element) within a parent item.A41
propertyterm
A required component of a simple data element name, or an optional component of a composite data element name or segment name. It is attached to an objectclassterm and indicates the salient features or characteristics of the dominant aspect of the name.A42qualifiedcompositedataelementa composite data element whose first component data element is a qualifier data element.A43qualifierdataelementa simple data element whose value is extracted from the relevant EDIFACT code table and gives a specific meaning to a composite data element or segment.
qualified segment
qualified segment
The first data element is a segment of a qualifier data element. A45qualifierterm
A name component that is a code value name in the code table of a qualifier data element. repeatingdataelementA46
A composite data element or an independent data element that has a maximum number of repetitions greater than 1 in a segment specification. representationterm
A required component of a simple data element name that defines and describes the format of the set of valid values ​​for a data element in a set of representationterms. scenario
A formal specification of a series of business activities with the same business objective. sectionalizedmessageA49
A message specification that is divided into two or more predefined sections. segment
A set of two identified, named, and structured composite and/or independent data elements that are functionally related and described in a segment specification. There are two types of segments: user segments and service segments. A51
segment collision
Ambiguous identification of segments that occurs when segments in a message instance are processed in sequence according to their ordinal positions in the message specification. A52
segment definition
Description of a segment that is unique to it and distinguishes it from all other segments. In document R.1023, this is called "segment description" in Chinese.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.