IEC62353-2014版标准解读及测试要求(文库版)

57/755/CDCOMMITTEE DRAFT (CD)Title:Data and Communication Security – Part 4: Profiles Including MMSIntroductory noteNOTE:At the request of the WG 15 convenor and in agreement with IEC Central Office, the TC 57 chairman andsecretary, the structure of the IEC 62351 series has been re-arranged as follows:IEC 62351-1: Data and Communication Security – Part 1: Introduction and OverviewIEC 62351-2: Data and Communication Security – Part 2: Glossary of TermsIEC 62351-3: Data and Communication Security – Part 3: Profiles Including TCP/IP.IEC 62351-4: Data and Communication Security – Part 4: Profiles Including MMS.IEC 62351-5: Data and Communication Security – Part 5: Security for IEC 60870-5 and DerivativesIEC 62351-6: Data and Communication Security – Part 6: Security for IEC 61850 Profiles.IEC 62351-7: Data and Communication Security – Part 7: Management Information Base (MIB)Requirements for End-to-End Network ManagementParts 1, 3, 4, 5, and 6 are circulated in May 2005, parts 2 and 7 will be circulated by the end of the year2005.All above-mentioned part numbers were covered by the original NWIPs and therefore no extra NWIP isrequired.(see next page)Copyright © 2005 International Electrotechnical Commission, IEC . All rights reserved. It ispermitted to download this electronic file, to make a copy and to print out the content for the solepurpose of preparing National Committee positions. You may not copy or "mirror" the file orprinted version of the document, or any part of it, for any other purpose without permission inwriting from IEC.57/755/CD2This document on cyber security cut across many traditional boundaries, and needs to be reviewed by alarger audience than the usual IEC TC57 working groups (although they are the primary audience).Therefore, it is suggested that the following organizations and groups be invited to review the document(as appropriate to their interests):●IEC TC57: WG03, WG07, WG10, WG15, WG16, WG17, WG18, WG19●Other IEC TCs: TC8, TC13 WG 14, TC88 WG25●ISO TC184/SC5 WG2●Cigre: CIGRÉ JWG D2/B3/C2 on Security - A. Torkilseng (NO)●ISA – SP99 "Bryan L Singer" bryan_singer@●American Gas Association (AGA) – Bill Rush●UCA International Users Group – Kay Clinard●DNP Users Group – Grant Gilchrist●IEEE: PSCC WG on Security Risk Assessment – Frances Cleveland, SCC36 – Frances Cleveland57/755/CD 3IEC 62351-4Committee Draft (CD)Version 1April, 2005Data andCommunications SecurityProfiles Including MMSContents1Scope and purpose (8)1.1Intended audience and use (8)2Normative References (8)3Definitions (9)4Profile Security (9)5Profile Security (10)5.1A-Profile (10)5.2MMS (10)5.3ACSE (11)5.3.1AARQ (13)5.3.2AARE (14)5.4T-Profile (14)5.4.1TCP T-Profiles (14)5.4.2OSI T-Profiles (17)6Annex 1 – IEC 60870-6 TASE.2 Security (18)List of FiguresFigure 1: TCP T-Profiles (14)List of TablesTable 1: TP0 Maximum Sizes (15)INTERNATIONAL ELECTROTECHNICAL COMMISSION____________Data and Communication SecurityFOREWORD1) The IEC (International Electrotechnical Commission) is a worldwide organisation for standardisation comprisingall national electrotechnical committees (IEC National Committees). The object of the IEC is to promote international co-operation on all questions concerning standardisation in the electrical and electronic fields. To this end and in addition to other activities, the IEC publishes International Standards. Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organisations liaising with the IEC also participate in this preparation. The IEC collaborates closely with the International Organisation for Standardisation (ISO) in accordance with conditions determined by agreement between the two organisations.2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, aninternational consensus of opinion on the relevant subjects since each technical committee has representation from all interested National Committees.3) The documents produced have the form of recommendations for international use and are published in theform of standards, technical specifications, technical reports or guides and they are accepted by the National Committees in that sense.4) In order to promote international unification, IEC National Committees undertake to apply IEC InternationalStandards transparently to the maximum extent possible in their national and regional standards. Any divergence between the IEC Standard and the corresponding national or regional standard shall be clearly indicated in the latter.5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for anyequipment declared to be in conformity with one of its standards.6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subjectof patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.This publication has been drafted in accordance with the ISO/IEC Directives, Part 2. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.This working draft of the International Standard IEC 62351 Part 3 has been prepared by IEC technical committee 57: Working Group 15 on Data and Communications Security.It is part of the standard series IEC 62351, a set of specifications for data and communication security. At time of publication of this part, the following parts are intended to be part of IEC 62351:•IEC 62351-1: Data and Communication Security – Introduction and Overview•IEC 62351-2: Data and Communication Security – Glossary of Terms•IEC 62351-3: Data and Communication Security – Profiles Including TCP/IP. These security standards cover those profiles used by IEC 60870-6 (TASE.2), IEC 60870-5Part 104, derivatives such as DNP3 over TCP/IP, and IEC 61850 over TCP/IP.•IEC 62351-4: Data and Communication Security – Profiles Including MMS. These security standards cover those profiles used by TASE.2 and IEC 61850.IEC 62351-6© IEC:2005 7 57/755/CD •IEC 62351-5: Data and Communication Security – Security for IEC 60870-5 and Derivatives (i.e. DNP3). These security standards cover both serial and networkedprofiles used by IEC 60870-5 and DNP.•IEC 62351-6: Data and Communication Security – Security for IEC 61850 Profiles.These security standards cover those profiles in IEC 61850-7-2 that are not based on TCP/IP – GOOSE, GSSE, and SMV.•IEC 62351-7: Data and Communication Security – Management Information Base (MIB) Requirements for End-to-End Network Management. These security standards define Management Information Base (MIBs) that are specific for the power industry, to handle network and system management through SNMP-based capabilities.IEC 62351 DATA COMMUNICATIONS SECURITY –Part 4: Communication Network and System Security - Profiles IncludingMMSEditors Note: Please note that Annex 1 is normative. IEC TC57 WG07 members need to decide if this annex should stay normative or to change it to informative. . If Annex 1 is made informative, then WG07 will need to take up an NWIP to reference this standard.Editors Note: Please note that the OSI T-Profile has not been secured within this standard. Comments are welcome for the establishment of a NWIP to profile OSI T-Profile security.1 Scope and purposeThis part of IEC 62351 specifies procedures, protocol extensions,, and algorithms to facilitate securing ISO 9506 – Manufacturing Message Specification (MMS) based applications. It is intended that this standard be referenced as a normative part of other IEC TC57 standards that have the need for using MMS in a secure manner.This standard represents a set of mandatory and optional security specifications to be implemented for applications when using ISO/IEC 9506 (Manufacturing Automation Specification).Note: Within the scope of IEC TC57, there are two identified standards that may be impacted: IEC 61850-8-1 and IEC 60870-6.This standard contains a set of specifications that are to be used by referencing standards in order to secure information transferred when using MMS. The recommendations are based upon specific communication profile protocols used in order to convey MMS information.The two identified IEC standards make use MMS in a 7-layer connection-oriented mechanism. Each of the standards are used over either the OSI or TCP profiles.1.1 Intended audience and useThe initial audience for this specification is intended to be the members of the working groups developing or making use of the protocols within IEC TC57. For the measures described in this specification to take effect, they must be accepted and referenced by the specifications for the protocols themselves, where the protocols make use of ISO 9506. This document is written to enable that process.The subsequent audience for this specification is intended to be the developers of products that implement these protocols.Portions of this specification may also be of use to managers and executives in order to understand the purpose and requirements of the work.2 Normative ReferencesStandard NameISO/ISP 14226-1:1996 Industrial automation systems -- International Standardized Profile AMM11: MMS General Applications Base Profile -- Part 1: Specification of ACSE, Presentation and Session protocols for use by MMSISO/ISP 14226-2:1996 Industrial automation systems -- International Standardized Profile AMM11: MMS General Applications Base Profile -- Part 2: Common MMS requirementsISO/ISP 14226-3:1996 1996 Industrial automation systems -- International Standardized Profile AMM11: MMS General Applications Base Profile -- Part 3: Specific MMS requirementsISO 9506-1 Industrial automation systems -- Manufacturing Message Specification -- Part 1: Service definitionISO 9506-2 Industrial automation systems -- Manufacturing Message Specification -- Part 2: Protocol specificationISO/IEC 8649 Information technology -- Open Systems Interconnection -- Service definitionfor the Association Control Service ElementISO/IEC 8650 Information technology -- Open Systems Interconnection -- Connection-oriented protocol for the Association Control Service Element: ProtocolspecificationIEC 61351-3 DATA COMMUNICATIONS SECURITY – Part 3: Communication Networkand System Security - Profiles Including TCP/IP3 DefinitionsSee IEC 62351-2.4 Profile SecurityThe communication security, specified in this standard, shall be discussed in terms of: •Application profiles: An A-Profile defines the set of protocols and requirements for layers 5-7 of the OSI Reference Model.•Transport profiles: A T-Profile defines the set of protocols and requirements for layers 1-4 of the OSI Reference Model.There have been one(1) A-Profile and two(2) T-Profiles identified within the TC57 context. This standard shall specify security extensions for all of the identified profiles.5 Profile Security5.1 A-Profile5.2 MMSThe implementation of MMS must provide some mechanism for configuring and making use of the capabilities of the secure profile. In general, there needs to be provided:• A mechanism for configuration of certificate information and the binding of that information to access authentication (e.g., the bilateral tables).• A mechanism for configuration of the acceptable incoming association profile for a given bilateral table. It is suggested that the following choices be provided:DON’T_CARE: would indicate either a secure or non-secure profile would be allowed to establish a MMS association.NON_SECURE: would indicate that the non-secure profile must be used in order to allow establishment of a MMS association.SECURE: would indicate that the secure profile must be used in order to allow establishment of a MMS association.• A mechanism for configuration of the profile to use in order to initiate a MMS association. It is suggested that the following choices be provided:NON_SECURE: would indicate that the non-secure profile must be used in order to allow establishment of a MMS association.SECURE: would indicate that the non-secure profile must be used in order to allow establishment of a MMS association.• A mechanism to convey/verify the association parameters. These parameters should include: Presentation Address; Profile used indication (e.g., secure or non-secure);and ACSE Authentication parameters. The indication of the use of a “secure profile”shall be reserved if the secure transport layer, as set forth within this document, has been negotiated as part of the MMS association1.This information shall be used, in conjunction with the configured MMS expected association values, to determine if a MMS association should be established. The entity that determines the actual acceptance is a local issue.It is a mandatory requirement that changes in the configuration parameters, discussed above, not require all MMS associations to be terminated in order for the configuration changes to take affect.It is strongly suggested that a MMS implementation log events and information associated with rejected associations that were rejected due to security violations.LoggingIt is important that care be taken to log security related violations in a separate log whose contents is inherently secure from manipulation (e.g., modification of information or deletion of information). Implementers should strive to archive enough information so that security audit and prosecution is facilitated. The actual implementation of this recommendation is a local issue.5.3 ACSEPeer entity authentication shall occur at association set up time. Authentication information shall be carried in the calling-authentication-value and responding-authentication-value fields of the authentication Functional Unit (FU) of the ACSE AARQ and AARE PDUs respectively. The bit strings for the sender-acse-requirements and responder-acse-requirements fields of the authentication FU shall be DEFAULTED to include the authentication FU, when ACSE security is in use. Otherwise, the bits shall be DEFAULTED to exclude the authentication FU (this provides backward compatibility).The calling-authentication-value and responding-authentication-value fields are of type Authentication-value that is further defined in ISO 8650 as a CHOICE. The CHOICE for the Authentication-value shall be EXTERNAL. The presentation context shall include a reference to the abstract syntax that is used for the EXTERNAL.The ACSE mechanism-name field shall be used to denote the format of the authentication-value field being conveyed. The definition of the mechanism-name field (both for AARQ and AARE) shall be:The ICCP authentication value (following ) shall be carried in the Authentication-value field of the authentication FU of ACSE. This value shall be used when peer entity authentication is required. The value shall be carried as the “external” as defined by the ACSE Authentication-value production (replicated below) as a SingleASN1Type.Note: The following production is a reproduction from ISO/IEC 8650 and is for informative purposes only.———————1 This allows for the ACSE Authentication to be used over either the secure or non-secure profiles to achievestronger authentication.Authentication-value ::= CHOICE {charstring [0] IMPLICIT GraphicString,bitstring [1] IMPLICIT BIT STRING,external [2] IMPLICIT EXTERNAL,other [3] IMPLICIT SEQUENCE {other-mechanism-nameMECHANISM-NAME.&id({ObjectSet}),other-mechanism-valueMECHANISM-NAME.&Type}}STASE-MMS-Authentication-value {iso member-body usa(840) ansi-t1-259-1997(0) stase(1) stase-authentication-value(0) abstractSyntax(1) version1(1)}DEFINITIONS IMPLICIT TAGS ::= BEGIN-- EXPORTS everythingIMPORTSSenderId, ReceiverId, Signature, SignatureCertificateFROM ST-CMIP-PCI {iso member-body usa(840) ansi-t1-259-1997(0) stase(1) stase-pci(1) abstractSyntax(4) version1(1)};MMS_Authentication-value ::= CHOICE{certificate-based [0] IMPLICIT SEQUENCE {authentication-Certificate [0] IMPLICIT &SignatureCertificate,time [1] IMPLICIT GENERALZEDTIME,signature [2] IMPLICIT &SignedValue},…}END&SignatureCertificateSignatureCertificate::= OCTET STRING -- size shall have a minimum-maximum size of 8192 octets.[Note:] The contents of the SignatureCertificate OCTET STRING shall be a Basic Encoding Rules encoded X.509 certificate (specified in CMIP). The certificate exchange shall be bi-directional and shall be a individual certificate from a configured and trusted certificate authority. If any of these conditions are not met, the connection shall be terminated appropriately.Identification of individual certificates shall be based upon the certificate Subject, as a minimum.In order to achieve interoperability of certificates, it is necessary to set a maximum allowed size for the certificates exchanged by ACSE. This size shall be limited to a maximum encoding size of 8192 octets.It is a local issue if a larger certificate can be accepted.If the certificate size exceeds the minimum-maximum (e.g. 8192) or the local maximum, then the connection shall be refused and a disconnect shall occur.&SignedValueThe value of the SignedValue shall be the value of the time field signed as specified by the PKCS#1 Version 2. The value is the encoded GENERAILZEDTIME string but does not include the ASN1 tag or length. This value shall be signed per the RSA signing algorithm in the specification. A key length of 1024 bits shall be supported as a minimum-maximum.The definition of the SignedValue shall be governed by the DigitalSignature definition found in RFC 2313:“For digital signatures, the content to be signed is first reduced to a message digest with a message-digest algorithm (such as MD5), and then an octet string containing the message digest is encrypted with the RSA private key of the signer of the content.The content and the encrypted message digest are represented together according to the syntax in PKCS #7 to yield a digital signature.”RFC 2437 (specification for PKCS#1 Version 2) specifies RSASSA-PKCS1-v1_5 as the signature algorithm, This is the algorithm that shall be used by implementations claiming conformance to this specification. The Hash algorithm shall be SHA1.timeThis parameter shall be the GENERALIZEDTIME representation of the GMT value of the time at which the Authentication-value was created.The accuracy of this time is a local issue but shall be as accurate as possible. It is equally valid to determine the value of the time parameter during the invocation of the MMS Intiate.Request service, Initiate.Response service, or during the encoding of the ACSE PDUs for those services.5.3.1 AARQThe sender of an AARQ shall encode the appropriate ACSE AuthenticationMechanism and AuthenticationValue fields and send the AARQ through the use of the Presentation-Connect service.The receiver of an AARQ-indication shall use the AuthenticationMechanism and AuthenticationValue fields to attempt to verify the signed value. If the decoded signed value is not equal to the value of the time field then the receiver shall cause a P-ABORT to be issued. If the time field value is more than ten (10) minutes2 difference from the local time, the receiver shall cause a P-ABORT to be issued.If the receiver of the AARQ has received the same signed value within the last ten (10) minutes, then the receiver shall cause a P-ABORT to be issued.———————2 This means that there is a window of vulnerability of 10 minutes in which the same signed value could be usedby an attacker.If the signed value has not caused a P-ABORT, then the signed value and other security parameters, shall be passed to the ACSE user (e.g., MMS or TASE.2 or the local Application). The method by which these parameters are passed is a local issue.5.3.2 AAREThe sender of an AARQ shall encode the appropriate ACSE AuthenticationMechanism and AuthenticationValue fields and send the AARQ through the use of the Presentation-Connect service.The receiver of an AARQ-indication shall use the AuthenticationMechanism and AuthenticationValue fields to attempt to verify the signed value. If the decoded signed value is not equal to the value of the time field then the receiver shall cause a P-ABORT to be issued. If the time field value is more than ten (10) minutes3 difference from the local time, the receiver shall cause a P-ABORT to be issued.If the receiver of the AARQ has received the same signed value within the last ten (10) minutes, then the receiver shall cause a P-ABORT to be issued.If the signed value has not caused a P-ABORT, then the signed value and other security parameters shall be passed to the ACSE user (e.g., MMS or TASE.2 or the local Application). The method by which these parameters are passed is a local issue.5.4 T-ProfileAn implementation that claims conformance to this standard shall support security for the TCP T-Profile as a minimum. An implementation may optionally support the security specifications for the OSI T-Profile.5.4.1 TCP T-ProfilesThe security recommendations for the TCP T-Profile do not attempt to specify security recommendations for TCP, IP, or Ethernet. Rather the specifications within this standard specify how to properly use Transport Layer Security and the securing of RFC-1006.The security TCP T-Profile inserts makes use of TLS (as specified by RFC 2246 ) to provide encryption and nodal authentication prior to RFC-1006.Figure 1: TCP T-Profiles———————3 This means that there is a window of vulnerability of 10 minutes in which the same signed value could be usedby an attacker.Figure 1 shows the two relevant TCP T-Profiles. One is the standard non-secure RFC-1006 T-Profile as specified by IETF. The other is the secure RFC-1006 profile that is specified within this standard.5.4.1.1 TPO5.4.1.1.1 Enforcement of maximum lengthsTP0 specifies the maximum size of TPDU. It is recommended that implementations use Table 1 to make sure that the RFC-1006 length does not exceed the maximum size. It is a local issue in regards to the processing of a TPDU whose RFC-1006 size is incorrect.Table 1: TP0 Maximum SizesOSI TP0 Primitive RFC-1006HeaderISO TP0 LI Field ISO TP0 User Data RFC-1006 Length Range Octets Minimum Maximum Minimum Maximum Mimum MaximumCR4 7 254 0 0 11 258 CC4 7 254 0 0 11 258 DR4 7 254 0 0 11 258 DC4 7 254 0 0 11 258 DT 4 3 3 1 204848 2055 ER4 5 254 0 0 9 259 ED Not Allowed due to TP0 restrictionAK Not Allowed due to TP0 restrictionEA Not Allowed due to TP0 restrictionRJ Not Allowed due to TP0 restriction5.4.1.1.2 Response to TP0 Unsupported TPDUsIt is recommended that the reception of an ED, AK, EA, or RJ TPDU be ignored.———————4 Maximum based upon negotiation of CR/CC exchange. 128 octets is the minimum allowed.5.4.1.1.3 Transport SelectorsThe International Standardized Profiles (ISP) for MMS specify that the Transport Selectors (TSELs) shall have a maximum size of thirty-two (32) octets. However, the parameterization of the selector according to ISO/IEC 8073, may have a length of 255 octets.An implementation that receives a TSEL whose length is greater than thirty-two (32) shall cause the connection to be aborted.5.4.1.2 RFC-1006It is recommended that the following enhancements be made to an RFC-1006 implementation when it is used in either the secure or non-secure T-Profile.5.4.1.2.1 Version NumberThe local implementation shall ignore the value of the RFC-1006 version field value. Local processing of the OSI TPDU(s) shall continue as if the field value was three (3).5.4.1.2.2 LengthThe RFC-1006 length field shall be limited to a value of no greater than 2056 octets. This length corresponds to the maximum TP0 TPDU allowed (e.g. 2048 octets).The processing of a length that is greater than 2056 is a local issue. However it is strongly suggested to disconnect the connection.5.4.1.2.3 Keep-aliveImplementations that claim conformance to this standard shall make use of the TCP-KEEPALIVE function. The timeout function should be set to approximately one (1) minute, or less.5.4.1.3 TLS Requirements5.4.1.3.1 TCP Port UsageThe non-secure T-Profile shall use TCP port 102 as specified by RFC-1006.Implementations claiming conformance to this standard shall use TCP port 3782 to indicate the use of the secure TCP T-Profile.5.4.1.3.2 Simultaneous SupportThe following requirement applies to implementations that claim support for more than one simultaneous MMS association. For such implementations, it shall be possible to communicate via the secure and non-secure T-profiles simultaneously.5.4.1.3.3 Use of TLSTransport Layer security shall be used as specified by IEC 62351-3.5.4.1.3.3.1 Cipher RenegotiationAn implementation that claims conformance to this specification shall support minimum-maximum renegotiation of: five-thousand (5000) ISO TPUs sent and/or ten(10) minutes elapsing from the previous renegotiation.5.4.1.3.3.2 Certificate SizeAn implementation that claims conformance to this specification shall support a minimum-maximum certificate size of 8192 octets. It is a local issue if larger certificates are supported.An implementation that receives a certificate larger than the size that it can support shall terminate the connection.5.4.1.3.3.3 Certificate RevocationThe default evaluation period for revoked certificates shall be twelve(12) hours. This evaluation period shall be configurable.An implementation that claims conformance to this standard shall terminate a connection where one of the certificates used to establish the connection is revoked.5.4.1.3.3.4 Mandatory Cipher SuitesIt is recommended that the following TLS cipher suites be considered for use:Recommended Cipher Suite CombinationsKey Exchange Encryption HashAlgorithm SignatureTLS_RSA_ WITH_RC4_128_ SHATLS_RSA_ WITH_3DES_EDE_CBC_ SHATLS_DH_ DSS_ WITH_3DES_EDE_CBC_ SHATLS_DH_ RSA_ WITH_3DES_EDE_CBC_ SHATLS_DHE_ DSS_ WITH_3DES_EDE_CBC_ SHATLS_DHE_ RSA_ WITH_3DES_EDE_CBC_ SHATLS_DH_ DSS_ WITH_AES_128_ SHATLS_DH_ DSS_ WITH_AES_256_ SHATLS_DH_ WITH_AES_128_ SHATLS_DH_ WITH_AES_256_ SHAAll implementations that claim conformance to this standard shall support at least TLS_HD_DSS_WITH_AES_256_SHA.Other standards that reference this standard may add additional mandatory cipher suites.5.4.2 OSI T-ProfilesThe security of OSI T-profiles is out-of-scope of this standard.6 Annex 1 – IEC 60870-6 TASE.2 SecurityEditors Note: Please note that this clause is normative. IEC TC57 WG07 members need to decide if this annex should stay normative or to change it to informative. . If this clause is made informative, then WG07 will need to take up an NWIP to reference this standard.IEC 60870-6 implementations, claiming to implement IEC TC57 standardized security, shall conform to this standard.。

电子电气产品聚合物材料中铅、镉元素的测试方法优化陆亚婷卿萌肖立姚华民（威凯检测技术有限公司广州510663）摘要：电子电气产品的广泛使用使人们更加关注其对环境的影响，欧盟2011/65/EU指令规定了电子电气设备中限制使用的六类有害物质，IEC 62321提供了六类有害物质的检测方法。

本文在IEC 62321-5:2013标准的基础上介绍了一种测试聚合物中铅、镉元素含量的干灰化优化方法。

使用国家标准物质进行方法确认,结果表明该方法准确度高，精密度、重复性好，检出限低，操作简便，适用于电子电气产品聚合物材料中铅、镉元素的大批量分析，对实验室提高检测效率，控制时间成本有积极意义。

关键词：IEC 62321-5：2013；铅、镉；干灰化法；优化聚合物材料由于具有优异的性能而被广泛用于电子电气产品中，但其在生产过程中添加的某些助剂却会对人体和环境产生危害[1] [2 [3]。

铅、镉作为被欧盟RoHS管控的有害物质，其检测方法向来受到行业关注。

IEC 62321-5：2013介绍了三种聚合物材料中铅、镉元素的测试方法：干灰化法，微波消解法和湿法消解法[4]。

三种方法的测试步骤见表1。

IEC 62321-5:2013中，干灰化法分析聚合物中铅、镉的前处理方法步骤繁琐，测试周期长，不利于快速分析样品；微波消解法受到仪器消解盘位少的限制，不利于大批量同时处理样品；湿法消解只能分析镉而不能同时分析铅元素，且前处理时间最长，不利于节约时间成本。

随着分析仪器智能化的水平不断提高，在整个测试环节中，影响检测结果准确度的因素更多的集中到了前处理的部分，因此前处理方法的选择及恰当的操作对于测定结果的正确性影响越来越大。

针对检测行业需批量化、高效率及低成本处理样品的要求，本文对IEC 62321-5：2013干灰化的方法进行了改进，在原标准的基础上提出了一个优化的干灰化法处理聚合物中铅、镉元素的方法。

该方法简化了试验步骤，操作相对简便，可同时分析铅、镉两种元素，同时具备了干灰化法可大批量分析样品，微波消解可简便准确分析样品的优点，提高了化学分析实验室做RoHS测试的效率。

iec62353 标准IEC 62353标准IEC 62353标准，也被称为医疗电气设备安全检测与试验的国际电工委员会标准，是全球范围内医疗设备安全性能评估的指导性文件。

该标准包括了医疗设备安全性能的要求以及相关试验方法。

本文将对IEC 62353标准进行详细介绍。

一、IEC 62353标准的背景与作用IEC 62353标准的制定目的是为了确保医疗电气设备的安全性能，并规范其在使用前的检测与试验流程，以保障患者和医护人员的生命与健康安全。

早期的医疗设备安全检测标准主要以IEC 60601系列标准为主，在实践中逐渐暴露出一些问题，如测试不全面、标准解释不一致等。

因此，IEC 62353标准作为一项重要的技术文件，于2007年首次由国际电工委员会发布，用于替代早期标准。

IEC 62353标准作为医疗设备安全性能检测的技术指南，主要适用于医疗电气设备的定期检测、维护与保养，并为医疗设备的日常使用提供了必要的保障。

该标准旨在对医疗电气设备进行电气安全性能检测，包括连接错误、绝缘、土地连接、漏电电流等指标的检测与评估。

二、IEC 62353标准的重要要求IEC 62353标准在医疗电气设备安全性能检测中提出了一些重要的要求，下面将对其进行逐一介绍：1. 测试环境要求：IEC 62353标准要求在设备检测过程中，应设置符合规范的测试环境，保证测试的准确和可靠性。

测试环境应包括相关的设备、设施和工作人员等。

2. 文件记录要求：检测过程中应当形成详细的文件记录，包括设备信息、测试值、测试结果等相关信息。

这些记录将为日后的维护和检修提供重要的参考依据。

3. 安全电压范围：IEC 62353标准对医疗电气设备的测试电压范围进行了规定，以保证在测试过程中的安全性。

测试电压的选择要根据设备的特性、额定电压和操作风险等因素进行合理选择。

4. 故障电流测试：该标准要求对医疗电气设备的故障电流进行测试，以评估设备在故障状态下的安全性能。

医疗设备国际电气安全标准IEC60601&62353对比
电子医疗设备通过电源或内部电源（电池）供电，通常用导线与患者进行连接。

部分设备配有可插入患者体内的活动部件，可以直接接触心脏。

此时，设备的漏电流对患者来说是一种风险，对接触医疗设备的临床医生护士同样也是风险。

电击可能会引起医疗程序的中断，并导致受伤或死亡。

所以，电气安全测试是医疗设备质控中最基础的，却又是最不可或缺的一个环节。

今天，我们就带着大家一分钟简单了解国际电气安全标准！
国际电气安全标准概述
为了协助验证医疗设备的功能性和安全性，美国、欧洲国家以及世界的其他部分已成立了电气安全标准。

总部设在欧洲的国际标准化组(ISO)和国际电工委员会(IEC)组织与世界贸易组织共同制定了全球标准。

包括针对电子医疗设备的标准。

有针对医疗设备电气安全的一般标准和具体标准。

关于IEC60601.1的其他重要点包括：
•使用高达25A交流电进行保护接地测试（为测试型，通常适用于制造商）•达到电源电压100%时测量泄漏电流
•达到电源电压110%时进行介电强度/绝缘测试测量
图2：符合IEC62353附录C的测试要求和顺序
IEC60601-1IEC62353
德国GMC Instruments，专业医疗设备安全测试仪器生产商，满足国际国内医
疗测试标准，为医疗设备质控管理助力！。