The Spec# Programming System Challenges and Directions. Position paper at VSTTE

The Spec#Programming System:

Challenges and Directions

Mike Barnett,Robert DeLine,Bart Jacobs,Manuel F¨a hndrich,

K.Rustan M.Leino,Wolfram Schulte,and Herman Venter

Microsoft Research,Redmond,W A,USA

mbarnett,rdeline,maf,leino,schulte,hermanv@https://www.wendangku.net/doc/c9257648.html,

bart.jacobs@cs.kuleuven.be

Manuscript KRML156,30September2005.

0Introduction

The Spec#programming system[2]is a new attempt to increase the quality of general purpose,industrial https://www.wendangku.net/doc/c9257648.html,ing old wisdom,we propose the use of speci?cations to make programmer assumptions https://www.wendangku.net/doc/c9257648.html,ing modern technology,we propose the use of tools to enforce the speci?cations.To increase its chances of having impact,we want to design the system so that it can be widely adopted.

For a programming system to be adopted widely,we think that it must:

–build on a widely used object-oriented programming language;in our case C#;

–build on existing infrastructure and allow interoperability with existing code,here https://www.wendangku.net/doc/c9257648.html, runtime.

–fully integrate into an development environment;in our case the Microsoft Visual Studio environment.

–build on a teachable and sound methodology;in our case a revised design-by-contract methodology;

–include tools that enforce the methodology;in our case this includes type checking, easily usable dynamic checking,as well as high-assurance automatic static veri?-cation;

–support a smooth adoption path whereby programmers can gradually start taking advantage of the bene?ts of speci?cation;

–be moderate;we added only a few constructs to C#,and soundness is guaranteed only as long as the source comes from constructs that are under our control.

In this extended abstract,we give an overview of the Spec#programming system, the rationale of its design,and a sketch of some open problems.Spec#is currently under development at Microsoft Research,Redmond.

1The Language

The Spec#language is a superset of C#,an object-oriented language targeted for the .NET Platform.C#features single inheritance whose classes can implement multiple

2

interfaces,object references,dynamically dispatched methods,and exceptions,to men-tion the features most relevant to this paper.

Spec#adds to C#type support for distinguishing non-null object references from possibly-null object references[12],method speci?cations like pre-and postconditions, a discipline for managing exceptions[18],and support for constraining the data?elds of objects[0].While conceptually simple,all have some complicated consequences. Next,we give an overview of each feature.

1.0Non-Null Types

Many errors in modern programs manifest themselves as null-dereference errors.We have opted to add type support for nullity discrimination to Spec#,because we think types offer the easiest way for programmers to take advantage of nullity distinctions. Here is a list of challenges with some solutions.

Initialization of?elds and arrays For type safety,any time a variable of a non-null type is read,the value obtained must be non-null.Without further restrictions,this is not guaranteed for instance?elds,static?elds,and array elements.Spec#offers a simple syntactic solution for instance?elds,which ensures that they are initialized before the object being constructed can be accessed.Handling non-null static?elds requires ordering restrictions on the initialization of classes.Spec#supports non-null static?elds,but the initialization restrictions are checked only at run time.

Supporting non-null element types of arrays is tricky,because there is no language construct that marks the end of the initialization of an array’s elements. Language interoperability https://www.wendangku.net/doc/c9257648.html, platform supports multiple languages,not all of which may be required to support non-null types.This raises many problems,like calling from such a language methods whose in-parameters have non-null types.

One could disallow such calls,but we want to encourage libraries to be updated with explicit non-null information without forcing changes in the clients.A better solution is to add non-null types to the virtual machine and to adapt the just-in-time compiler,but this would greatly impact all virtual-machine implementations.

Arrays with non-null element types also require changes in the virtual machine, because of array covariance.For this reason,we do not support them in Spec#. Stability of non-nullity One must support some form of down-cast of an expression from a maybe-null type to a non-null type.The Spec#compiler infers the non-nullity of local variables by performing a data-?ow analysis that takes into account type casts and tests for null.However,this is problematic for?elds,whose values may be changed between a test and a use by calls or by other threads about which the compiler has no information.

Non-null types with various degress of type soundness have also been used in pro-gram checking systems like LCLint[11]and are being incorporated into the object-oriented language Eiffel[20];see F¨a hndrich and Leino’s paper[12]for more informa-tion about previous work.

3 1.1Method Contracts

To allow programmers to capture more complicated properties,which may involve more than one variable,we advocate using general speci?cations instead of further enrich-ments to the type system.Like for example Eiffel[19],Spec#supports pre-and post-conditions of methods;these use ordinary side-effect free boolean expressions. Inheritance Pre-and postconditions are inherited in method overrides.Spec#allows overrides to declare additional postconditions.However,Spec#does not allow an override to weaken the precondition,despite the fact that this would be sound.

Here’s our justi?cation:There is a mindset https://www.wendangku.net/doc/c9257648.html,(and in Java)that the misuse of language primitives(like indexing an array outside its bounds)and methods always be detected and reported immediately when the violation occurs at run time.

It would seem to go against this mindset to allow an override to eliminate this detection.Actually,though a?ne syntactic convenience,there is never a need for weakening preconditions,because a subclass can always de?ne a new method with

a weaker precondition and let the old method call the new one.

Because of interfaces,there is a limited form of multiple inheritance.In these cases,

a method implementation can inherit its speci?cation from several sources.How-

ever,to avoid weakening preconditions,Spec#allows this multiple inheritance only in certain situations where all the inherited preconditions are the same.Actually, this is not a semantic restriction in Spec#,because a class can provide different implementations for multiply inherited methods.

Frame conditions To reason statically about a call,one needs to know what variables the callee may modify.Specifying this frame condition is dif?cult,because of in-formation hiding:the frame condition must say that the caller’s variables are un-changed and must allow the implementation’s variables to be changed.But these variables are in general not visible to both the caller and the implementation.Spec# uses syntactic and semantic abstractions to address this problem,but we do not yet have enough evidence to evaluate whether or not this particular solution is the right one.

Evaluation of contracts We take the view that contracts should contribute to the spec-i?cation of programs,but not to their effects.Therefore,Spec#insists that expres-sions used in contracts are side-effect free.We do allow procedural abstraction in contracts,as long as any procedure(method,rather)called also is side-effect free, that is,pure.A syntactic notion of purity is overly restrictive,so we are exploring notions of behavioral purity,but don’t have all the answers yet[4,22].

The fact that contracts are given by expressions of the language raises the problem that the evaluation of those expressions can fail.Spec#chooses to hold the spec-i?cation writer accountable for such errors.That is,contracts are enforced to be totally de?ned.

1.2Class Contracts

Invariants are key to describing the correctness of programs,and Spec#allows classes to declare invariants that describe the internal consistency of the state of their objects.

4

However,the problem of maintaining invariants that span several objects has been under-studied.Two central problems are delineating when an object invariant holds (which is made dif?cult because of re-entrancy)and controlling changes to sub-objects (which is made dif?cult because references to these sub-objects may be leaked).

Spec#uses a sound methodology that addresses both of these central problems(and the problem of writing frame conditions)[0,15,3,16].Spec#provides a block state-ment that delineates where object invariants may temporarily be violated,and it uses ownership domains to con?ne references.

1.3Concurrency

Multi-threading introduces the possibility of race conditions and deadlocks.This makes data consistency even more dif?cult to achieve in a multi-threaded program.We feel that a programming methodology should permit extensions that cover concurrent programs, too.We have formulated an extension of our object-invariant methodology for multi-threading[13].It ensures mutual exclusion on ownership domains and maintains data consistency.But our extension still has several shortcomings,including:it does not check for deadlocks and its locking is sometimes too coarse-grained.

1.4Data Abstraction

More elaborate speci?cations of programs require a way to present a view of objects that abstracts away from implementation details.We?nd that this form of data abstraction already exists in https://www.wendangku.net/doc/c9257648.html, programs in the form of properties(which are essentially parameter-less methods).If a property is a pure function of the state of an object and its immediate ownership domain,then we call it a model?eld[7,14,17,21].We are hopeful that one can formulate the de?nition and use of model?elds in a way that is amenable to static program veri?cation.

2System Architecture

Architecturally,the Spec#programming system consists of the compiler,a runtime li-brary,and the static program veri?er.Spec#has been integrated into the Microsoft Vi-sual Studio environment.For example,violations of the non-null type system are in-dicated by“red squigglies”,speci?cations of methods(including any speci?cations on library methods)are available in tool tips.The static program veri?er runs continuously while editing the program and interactively produces red squigglies for semantic errors, but it can also be run as a standalone tool.

2.0Levels of Checking

Spec#provides three levels of checking.

The?rst level of checking is provided by the type checker,which runs as part of the compiler and which must accept the program before any code is emitted.The type

5 checker is stronger than some other traditional type checkers in that it is sometimes sensitive to data?ow.

The second level of checking is provided by compiler-emitted run-time checks. These checks are always emitted,but we do provide some compiler options that dis-able them,because development organizations sometimes feel they have reached a point in the development cycle where they are willing to risk not having the checks and would rather gain performance.The run-time checks enforce many contracts,but do not enforce the entire Spec#programming methodology.For example,frame condi-tions(modi?es clauses)are not checked at run time and,by default,ownership domains are not enforced at run time.

The third level of checking,which is optional,is provided by the Spec#static pro-gram veri?er.It enforces all contracts and the entire Spec#programming methodology, except assume statements,which are provided for the speci?c purpose of introducing a run-time check for programmer assumptions that would take great effort to prove statically.

2.1Contract Persistence

The Spec#compiler preserves the speci?cations as metadata in the same binary assem-bly as the compiled code.This enables reuse of speci?cations across tools.

To enable clients of a legacy library to be veri?ed,such a library needs to be retro?tted with speci?cations.If the library cannot be converted into Spec#,we support the compilation and use of out-of-band contracts in shadow assemblies.These give the illusion that the speci?cations were declared in the library itself.

2.2Static Veri?cation

From MSIL(https://www.wendangku.net/doc/c9257648.html, bytecode),Spec#’s static program veri?er(whose codename is Boogie)constructs a program in its own intermediate language,BoogiePL[10].Boo-giePL is a simple imperative language with procedures.BoogiePL also supports the introduction of uninterpreted function symbols and axioms,which makes it suitable as a stepping stone in program veri?cation.In fact,all of the Spec#to be veri?ed is trans-lated into BoogiePL,including the axiomatization of the Spec#type system,etc.From the BoogiePL program,Boogie infers loop invariants using abstract interpretation[8, 9,5,6]and generates veri?cation conditions(logical formulas that are valid iff the pro-gram is correct)that it passes to an automatic theorem prover[1].Counterexamples reported by the theorem prover are translated back into error messages about the source code,which are reported to the user.

Technology for abstract interpretation and theorem proving exist.We feel that the work in this area has reached the kind of maturity where what is needed for Spec# consists mainly in adapting and tuning existing technologies for the veri?cation task at hand.One difference from previous work is perhaps the emphasis on the heap in Spec#programs.There is also room for improving the combination of various abstract domains as well as exploring the combination of abstract domains and decision proce-dures.

6

In the veri?cation community,various standard or canonical formats have been useful for interoperability,substitutability,and evaluation of tools(for example,the primitive DIMAC format for SAT formulas).Our position is that BoogiePL is a good candidate for playing that same role in the space of verifying programs.Boogie can be invoked not just on MSIL assemblies,but also on BoogiePL programs directly. This means that other researchers can reuse the abstract interpretation and veri?cation-condition generation in Boogie.

3Conclusion

We are excited about the Veri?cation Grand Challenge working conference.We see the largest remaining challenge to be the formulation of programming methodology that allows modern programs to be speci?ed and veri?ed,as well as the serious engineering effort to build such a programming system.

The Spec#system,including the Boogie program veri?er,can be downloaded from https://www.wendangku.net/doc/c9257648.html,/SpecSharp.

References

0.Mike Barnett,Robert DeLine,Manuel F¨a hndrich,K.Rustan M.Leino,and Wolfram Schulte.

Veri?cation of object-oriented programs with invariants.Journal of Object Technology,3(6), 2004.www.jot.fm.

1.Mike Barnett and K.Rustan M.Leino.Weakest-precondition of unstructured programs.

In Proceedings of the2005ACM SIGPLAN-SIGSOFT Workshop on Program Analysis For Software Tools and Engineering,PASTE2005.ACM,September2005.

2.Mike Barnett,K.Rustan M.Leino,and Wolfram Schulte.The Spec#programming system:

An overview.In CASSIS2004,Construction and Analysis of Safe,Secure and Interoperable Smart devices,volume3362of Lecture Notes in Computer Science,pages49–69.Springer, 2005.

3.Mike Barnett and David A.Naumann.Friends need a bit more:Maintaining invariants over

shared state.In Seventh International Conference on Mathematics of Program Construction (MPC2004),Lecture Notes in Computer Science.Springer-Verlag,July2004.

4.Mike Barnett,David A.Naumann,Wolfram Schulte,and Qi Sun.99.44%pure:Useful

abstractions in speci?cations.Proceedings,6th workshop on Formal Techniques for Java-like Programs,June2004.

5.Bor-Yuh Evan Chang and K.Rustan M.Leino.Abstract interpretation with alien expressions

and heap structures.In Radhia Cousot,editor,VMCAI2005,volume3385of Lecture Notes in Computer Science,pages147–163.Springer,January2005.

6.Bor-Yuh Evan Chang and K.Rustan M.Leino.Inferring object invariants.In Proceedings

of First International Workshop on Abstract Interpretation of Object-Oriented Languages (AIOOL2005),2005.

7.Yoonsik Cheon,Gary T.Leavens,Murali Sitaraman,and Stephen Edwards.Model variables:

cleanly supporting abstraction in design by contract.Software—Practice and Experience, 35(6):583–599,2005.

8.Patrick Cousot and Rhadia Cousot.Abstract interpretation:a uni?ed lattice model for static

analysis of programs by construction or approximation of?xpoints.In Conference Record of the Fourth Annual ACM Symposium on Principles of Programming Languages,pages 238–252.ACM,January1977.

7 9.Patrick Cousot and Nicolas Halbwachs.Automatic discovery of linear restraints among

variables of a program.In Conference Record of the Fifth Annual ACM Symposium on Principles of Programming Languages,pages84–96,January1978.

10.Robert DeLine and K.Rustan M.Leino.BoogiePL:A typed procedural language for check-

ing object-oriented programs.Technical report,Microsoft Research,2005.

11.David Evans,John V.Guttag,James J.Horning,and Yang Meng Tan.LCLint:A tool for

using speci?cations to check code.In David S.Wile,editor,SIGSOFT’94,Proceedings of the Second ACM SIGSOFT Symposium on Foundations of Software Engineering,ACM SIGSOFT Software Engineering Notes19(5),pages87–96,December1994.

12.Manuel F¨a hndrich and K.Rustan M.Leino.Declaring and checking non-null types in an

object-oriented language.In Ron Crocker and Guy L.Steele Jr.,editors,Proceedings of the 2003ACM SIGPLAN Conference on Object-Oriented Programming Systems,Languages and Applications,OOPSLA2003,volume38,number11in SIGPLAN Notices,pages302–312.

ACM,October2003.

13.Bart Jacobs,K.Rustan M.Leino,Frank Piessens,and Wolfram Schulte.Safe concurrency for

aggregate objects with invariants.In Bernhard K.Aichernig and Bernhard Beckert,editors, 3rd International Conference on Software Engineering and Formal Methods,pages137–146.

IEEE,September2005.

14.Gary T.Leavens,Albert L.Baker,and Clyde Ruby.Preliminary design of JML:A behav-

ioral interface speci?cation language for Java.Technical Report98-06-rev28,Iowa State University,Department of Computer Science,2003.See https://www.wendangku.net/doc/c9257648.html,.

15.K.Rustan M.Leino and Peter M¨u ller.Object invariants in dynamic contexts.In Martin

Odersky,editor,European Conference on Object-Oriented Programming(ECOOP),volume 3086of Lecture Notes in Computer Science,pages491–516.Springer-Verlag,2004.

16.K.Rustan M.Leino and Peter M¨u ller.Modular veri?cation of static class invariants.In

Formal Methods2005,July2005.

17.K.Rustan M.Leino and Greg Nelson.Data abstraction and information hiding.ACM Trans-

actions on Programming Languages and Systems,24(5):491–553,September2002.

18.K.Rustan M.Leino and Wolfram Schulte.Exception safety for C#.In Jorge R.Cuellar and

Zhiming Liu,editors,SEFM2004—Second International Conference on Software Engineer-ing and Formal Methods,pages218–227.IEEE,September2004.

19.Bertrand Meyer.Object-oriented Software Construction.Series in Computer Science.

Prentice-Hall International,New York,1988.

20.Bertrand Meyer.Attached types and their application to three open problems of object-

oriented programming.In ECOOP2005,pages1–32.Springer,July2005.

21.Peter M¨u ller.Modular Speci?cation and Veri?cation of Object-Oriented Programs,volume

2262of Lecture Notes in Computer Science.Springer,2002.

22.David A.Naumann.Observational purity and encapsulation.In Maura Cerioli,editor,Fun-

damental Approaches to Software Engineering,8th International Conference,F ASE2005, volume3442of Lecture Notes in Computer Science,pages190–204.Springer,April2005.

紧固件材料的选择(螺栓、螺母)

1、紧固件六角头螺栓、等长双头螺栓、全螺纹及螺栓螺母、螺柱螺纹未端采用GB两倒角端型式。 2、紧固件规格 管法兰用紧固件规格采用：M10、M14、M16、M20、M22、M24、M27、M30、M33、M36*3、M39*3、M45*3、M48*3、M56*3、M64*3、M70*3、M76*3、M90*3。 常用紧固件用规格符合GB5782要求及GB901-B级规定。 ３、机械性能 采用GB3098.1 螺栓8.8级；螺母8级。 采用中国石油化工行业标准： 螺栓、螺柱采用：35#、40CR、30CRMO、35CRMOA、25CR2MOVA材料牌号。 螺母采用：25#、40CR、35CRMOA、25CR2MOVA等材料牌号。 其它机械性能指标： 指标强度在800MPa-900MPa以上。 屈服强度在640MPa-720MPa以上。 伸长率在12-15%以上。 硬度HRC25-35%。 2008-4-22 9:46:17 标准紧固件网 紧固件材料 一、目前市场上标准件主要有碳钢、不锈钢、铜三种材料。 （一）碳钢。我们以碳钢料中碳的含量区分低碳钢，中碳钢和高碳钢以及合金钢。 1、低碳钢C%≤0.25% 国内通常称为A3钢。国外基本称为1008，1015，1018，1022等。主要用于4.8级螺栓及4级螺母、小螺丝等无硬度要求的产品。（注：钻尾钉主要用1022材料。） 2、中碳钢0.25%≤0.45% 国内通常称为35号、45号钢，国外基本称为1035，CH38F，1039，40ACR等。主要用于8级螺母、8.8级螺栓及8.8级内六角产品。 3、高碳钢C%>0.45%。目前市场上基本没使用 4、合金钢：在普碳钢中加入合金元素，增加钢材的一些特殊性能：如3 5、40铬钼、SCM435，10B38。芳生螺丝主要使用SCM435铬鉬合金钢，主要成分有C、Si、Mn、P、S、Cr、Mo。 （二）不锈钢。性能等级：45，50，60，70，80 主要分奥氏体（18%Cr、8%Ni）耐热性好，耐腐蚀性好，可焊性好。A1，A2，A4 马氏体、13%Cr耐腐蚀性较差，强度高，耐磨性好。C1，C2，C4铁素体不锈钢。18%Cr镦锻性较好，耐腐蚀性强于马氏体。目前市场上进口材料主要是日本产品。按级别主要分SUS302、SUS304、SUS316。

开关电源测试规范

开关电源测试规范 By ZGQ 一、概述 本文主要阐述了开关电源必须通过一系列的测试，使其符合所有功能规格、保护特性、安规（如UL、CSA、VDE、DEMKO、SEMKO，长城等之耐压、抗燃、漏电流、接地等安全规格）、电磁兼容（如FCC、CE等之传导与幅射干扰）、可靠性（如老化寿命测试）、及其他特定要求等。 测试开关电源是否通过设计指标，需要各种精密的电子设备去模拟电源在各种环境下实际工作中的性能。下面是开关电源一些测试项目： 1.功能(Functions)测试： ·电压调整率测试(Line Regulation Test) ·负载调整率测试(Load Regulation Test) ·输出纹波及噪声测试(Output Ripple & Noise Test) ·功率因数和效率测试(Power Faction & Efficiency Test) ·能效测试（Energy Efficiency Test） ·上升时间测试（Rise Time Test） ·下降时间测试（Fall Time Test） ·开机延迟时间测试（Turn On Delay Time Test） ·关机保持时间测试（Hold Up Time Test） ·输出过冲幅度测试(Output Overshoot Test) ·输出暂态响应测试（Output Transient Response Test） 2.保护动作(Protections)测试： ·过电压保护(OVP, Over Voltage Protection) ·短路保护(Short Circuit Protection) ·过电流保护(OCP, Over Current Protection) 3.安全(Safety)规格测试： ·输入电流、漏电电流等 ·耐压绝缘: 电源输入对地，电源输出对地；电路板线路须有安全间距。 ·温度抗燃：零组件需具备抗燃之安全规格，工作温度须於安全规格内。 ·机壳接地：需於0.1欧姆以下，以避免漏电触电之危险。 ·变压输出特性：开路、短路及最大伏安(VA)输出 ·异常测试：散热风扇停转、电压选择开关设定错误 4.电磁兼容(Electromagnetic Compliance)测试： 5.可靠性(Reliability)测试： 6.其他测试： 二、电气特性(Electrical Specifications)测试

通知的格式写法修订版

通知的格式写法 Document number：PBGCG-0857-BTDO-0089-PTT1998

通知的格式、写法 通知是一种使用范围较广的文体。凡需要特定机关和人员知道、办理的事宜，都可以用通知。但也不能因为通知便于使用而滥用通知。 通知可分为“发布性通知”、“批转性通知”、“事项性通知”、“会议性通知”、“任免通知”五种。这里仅介绍“事项性通知”、“会议性通知”、“任免通知”三种。 1、事项性通知。在上级机关的有关事宜需要使下级机关知道或办理时，如：庆祝某个节日，成立、调整、合并、撤销某个机构，启用印章，更正文件差错，请下级机关报送有关材料等，都可使用这种通知。这种通知，要交待清楚所通知的事项，如何办理，有什么要求等。 2、会议通知。上级机关要召开比较重要的会议时，一般都要提前通知所属有关单位，这就是会议通知。这种通知要求写得明确具体，交待清楚会议名称、主持单位、会议内容、起止时间、参加人员、会议地点、报到地点、携带材料以及其他有关事宜。如果这些事项交待不清，丢三拉四，就可能影响会议的按时召开和正常进行。 3、任免通知。上级机关在任免下级机关的领导人或上级机关的有关任免事项需要下级机关知道时要发任免通知。这种通知的写法比较简单，一般只要写清楚决定任免的时间、机关、会议或依据文件，以及任免人员的具体职务即可。 不论哪种类型的通知，都应该注意以下几点： 1、通知一般都要有一个符合标题“三要素”（即发文机关、事由、文种）的标题，使人一看标题就知道是通知什么事情或要求做什么事情。有些机关简单地使用“通知”作标题，这是不确切的，应尽量避免，更不应提倡。 2、被通知单位就是文件的主送单位，有的通知往往不写被通知单位，这是不妥当的。 3、如果所通知的事项需要被通知的单位尽快知道，可在“通知”之前加“紧急”二字，这就是常见的“紧急通知”。

(整理)凯诺标准件螺栓和螺母检测方法1.

标准件外、内螺纹检测方法 一、外螺纹检测方法：（等级为中等6g） ◆大径： （1）测试方法： 1：用通端光滑卡规卡工件外螺纹，并应能顺利通过；用止端光滑卡规卡工件外螺纹，不应通过 2：用外径千分尺，在测试部位任意相互垂直的两个直径方向上进行测量（测量尺寸见附表） （2）测量工具： GB/T 3934规定的通、止端光滑卡规 GB/T 1216规定的千分尺 ◆作用中径和小径： （1）测量方法： 用手将通端螺纹环规旋入工件外螺纹，并应能顺利通过 （2）测量工具： GB/T 3934规定的通端光滑卡规 ◆单一中径： （1）测量方法： 用手将止端螺纹环规旋入工件外螺纹，但不得超过两个螺距（拧退环规起计算） （2）测量工具： GB/T 3934规定的止端光滑卡规 ◆说明 （1）检测所选用的通、止规应与供应商选用的产品相一致，镀前选用6g等级的通、止规检测，镀后选用6h等级的通、止规检测 （2）性能等级8.8级，按GB/T 3098.1-2000标准执行 （3）热处理硬度HRC22—32 （4）产品一次性检验的废品率为1/1000 （5）交货状态下产品表面均匀一致，无划痕、损伤 （6）其他部位的尺寸执行GB/T5276标准或根据客户要求 （7）不锈钢标准件物理性能检测应符合GB/T 3098.6-2000中要求 二、内螺纹的检验方法：（等级为中等6H） ◆小径： （1）测试方法： 用手将通端光滑塞规塞入工件内螺纹，并应能顺利通过（不包括锁紧螺母的有效力矩部分）；用手将止端光滑塞规塞入内螺纹的两端（如图所示）应符合以下规定：

1+ 2 0.5 薄螺母两端进入量之和： 1+ 2 0.65 2：用数显卡尺，在测试部位任意相互垂直的两端内径方向上进行测量（测量尺寸见附表） （2）测量工具： GB/T 3934规定的通、止端光滑塞规 GB/T 1216规定的数显卡尺（0.02mm） ◆作用中径和大径： （3） （4）测量方法： 用手将通端螺纹塞规旋入工件内螺纹，并应能顺利通过（不包括锁紧螺母的有效力矩部分） （5）测量工具： GB/T 3934规定的通端光滑塞规 ◆单一中径： （3）测量方法： 用手将止端螺纹塞规旋入工件内螺纹两端的螺纹部分，每端不得超过两个螺距（拧退环规起计算），对三个或少于三个的内螺纹，亦不应完全旋合通过 （4） （5）测量工具： GB/T 3934规定的止端光滑塞规 ◆说明 （1）检测所选用的通、止塞规应与供应商选用的产品相一致，镀前选用6G等级通、止规检测，镀后选用6H等级的通、止规检测 （2）性能等级8.8级，按GB/T 3098.1-2000标准执行 （3）热处理硬度HRC22—32 （4）产品一次性检验的废品率为1/1000 （5）交货状态下产品表面均匀一致，无划痕、损伤 （6）其他部位的尺寸执行GB/T5276标准或根据客户要求

Ch_11_Intel_Pkg_Spec

International Packaging Specifications 11 11.1Electronic Industries Association of Japan (EIAJ) EIAJ publishes the following rules and standards as they apply to the preparation of outline drawings of integrated circuits. Number Nomenclature ED -7300Recommended practice on standard for the preparation of outline drawings of semiconductor packages ED -7301Manual or the standard of integrated circuits package ED -7302Manual for integrated circuits package design guideline ED -7303Name and code for integrated circuits package ED -7304Measuring method for package dimensions of ball grid array (BGA) ED -7304-1Measuring method for package dimensions of Small Outline Package (SOP) ED -7304-2Measuring method for package dimensions of Small Outline J-leaded package (SOJ) ED -7305Unit design guide for the preparation of package outline drawing of integrated circuits (gullwing-lead) ED -7311Standards of integrated circuits package ED -7311-1Standard of integrated circuits package [TSOP(1)] ED -7311-2Standard of integrated circuits package [TSOP(2)] ED -7311-3Standard of integrated circuits package [Tape Ball Grid Array 1.0mm pitch (T-BGA)] ED -7311-4Standard of integrated circuits package [Tape Ball Grid Array 1.27mm pitch (T-BGA)] ED -7311-5Standard of integrated circuits package [32/48 pins Fine-pitch Ball Grid Array (FBGA)] ED -7311-6Standard of integrated circuits package [60/90 pins Fine-pitch Ball Grid Array (FBGA)] ED -7311-7Standard of integrated circuits package [Plastic Fine pitch Ball Grid Array (P-FBGA)] ED -7311-8Standard of integrated circuits package [Plastic Fine pitch Ball Grid Array 0.8mm pitch (P- FBGA)] ED -7311-9A Standard of integrated circuits package [P-BGA (Cavity up type)] ED -7311-10A Standard of integrated circuits package [P-BGA (Cavity down type)] ED -7311-11A Standard of integrated circuits package (119/153 pins P-BGA) ED -7311-12Standard of integrated circuits package (52 pins 64 pins 80 pins and 100 pins low-profile quad flat package with exposed heatsink) ED -7400Standards for the dimensions of semiconductor devices (integrated circuits) ED -7400-1Standards for the dimensions of semiconductor devices (integrated circuits) ED -7400-2Standards for the dimensions of semiconductor devices (integrated circuits) ED -7401-4Method of measuring semiconductor device package dimensions (integrated circuits) ED -7405General rules for the preparation of outline drawings of integrated circuits zigzag in-line packages (ZIP) ED -7405-1General rules for the preparation of outline drawings of integrated circuits shrink zigzag in-line packages (SZIP)

开关电源 安规要求

安规知识解读 以下如未特别说明，安规要求均指GB4943-2001 1、基本绝缘：对防电击提供基本保护的绝缘。 2、加强绝缘：除基本绝缘外施加的独立的绝缘，用于确保基本绝缘一旦失效时仍 能防止电击。 3、电气间隙（clearance）：两个导电零部件之间的最短空间距离。 4、爬电距离（creepage distance）：沿绝缘表面测得的两个导电零部件之间的最短 路径。 5、Y1电容可以认为具有加强绝缘的功能。 初—次级跨接的电容用Y1 初—地之间可用Y2电容(1.5.7.1) ?工程师设计时常见错误： 没有Y1和Y2电容的使用概念，以致初---次级之间也“不知不觉”地用了Y2电容。 6、设备的防电击保护类别： Ⅰ类设备：采用基本绝缘，而且有保护接地导体； Ⅱ类设备：采用双重绝缘，这类设备既不依靠保护接地，也不依靠安装条件的保护措施； Ⅲ类设备：SELV供电，且不会产生危险电压； 7、电源上的铭牌标示 i.电源额定值标志 1）额定电压及电流 对具有额定电压范围的设备:

100V—240V; 2.8A 100V—240V; 2.8—1.1A 200V—240V; 1.4A 对多个额定电压: 120/ 220V ; 2.4/1.2A 2)电源的性质符号: 直流——交流~(GB8898-2001) ii.制造厂商名称或商标识别标记 iii.型号 iv.符号“回”，仅对Ⅱ类设备适用。

?工程师设计时常见错误： Ⅱ类设备大标贴没有“回”字符 没有LOGO或LOGO与认证证书不是同一公司 交流输入性质用“AC”表示，不用“~”表示 具有额定电压范围或多个额定电压的设备，电流标示本应是“100V—240V; 2.8—1.1A”或“120/ 220V ; 2.4/1.2A”，错写成“100V—240V; 1.1—2.8A” 或“120/ 220V ; 1.2/2.4A” 8、保护接地和等电位连接端子标示 预定要与保护接地导线相连的接线端子 应标示符号，该符号不能用于其它接地端子。 对保护连接导线的端子不要求标示，

通知的格式与范文

通知的介绍、写作格式与范文一通知的适用范围及特点 通知适用于批转下级机关的公文，转发上级机关和不相隶属机关的公文,发布文件；传达要求下级机关办理和需要有关单位周知或者执行的事项；任免人员。 通知是各级党政机关、人民团体、企事业单位在公务活动中最常用的一种公文，使用范围相当广泛。 通知具有三个特点： 1．使用范围具有广泛性。通知不受发文机关级别高低的限制；对通知的行文路线限制不严，主要作上级机关对下级机关、组织对所属成员的下行文，但平行机关之间、不相隶属的机关之间，有时也可使用通知知照有关事项；通知写作灵活自由，使用比较方便。 2．文种功用多具有指导性。上级机关和组织向下级机关、组织用通知行文，都明显体现出指导性。特别是部署和布置工作、批转和转发文件等，都需明确阐述处理某些问题的原则和方法，说明需要做什么，怎样做，达到什么要求等。一部分通知对下级或有关人员有约束力,起指挥、指导作用;另一部分通知则主要起知照作用。 3．有明显的时效性。通知事项一般是要求立即办理、执行或知晓的，不容拖延。有的通知如会议通知，只在指定

的一段时间内有效。 二通知的主要类型 根据内容与作用，通知可分为以下几种类型： 1．指示性通知。有关行政法规和规章、办法、措施，不宜用命令(令)发布的，可使用这种通知行文。指示性通知往往带有强制性、指挥性和决策性的特点。 2．批示性通知(批转、转发性通知)。用于发布某些行政法规，转发上级、同级或不相隶属机关的公文以及批转下级机关的公文。这类通知包括批转性和转发性两种。批转性通知，适用于上级机关对下级部门的文件加批语下发，需在标题中加“批转”两字；转发性通知是“转发”有关文件的通知，同样需在标题中注明“转发”字样。 3．事项性通知(工作通知)。要求下级机关办理某些事项，除交待任务外，通常还提出工作原则和要求，让受文单位贯彻执行，具有强制性和行政约束力，这种通知，便属事项性通知。有些工作任务，不宜采用命令和意见行文的，可使用这种通知。 4．知照性通知。用于告知某一事项或某些信息的通知，诸如庆祝节日，成立、调整、合并、撤销机构，人事任免，启用新印章，更改电话，更正文件差错等，都可用这种通知行文。 5会议通知。即告诉有关单位或个人参加会议的通知。

常用螺栓的标准及规格表

常用螺栓的标准及规格表 国家标准规定了螺纹规格为M3~M64,A和B级的六角头螺栓.A级用于D<=24和L<=10D或 L<=150mm(按较小值)的螺栓;B级用于D>24或L>10D或L>150(按较小值)的螺栓 外六角螺栓尺寸规格(如图) 钢结构连接用螺栓性能等级分、、、、、、、、等10余个等级，其中级及以上螺栓材质为低碳合金钢或中碳钢并经热处理（淬火、回火），通称为高强度螺栓，其余通称为普通螺栓。螺栓性能等级标号有两部分数字组成，分别表示螺栓材料的公称抗拉强度值和屈强比值。例如，性能等级级的螺栓，其含义是： 1、螺栓材质公称抗拉强度达400MPa级； 2、螺栓材质的屈强比值为； 3、螺栓材质的公称屈服强度达400×=240MPa级 性能等级级高强度螺栓，其材料经过热处理后，能达到： 1、螺栓材质公称抗拉强度达1000MPa级； 2、螺栓材质的屈强比值为； 3、螺栓材质的公称屈服强度达1000×=900MPa级 螺栓性能等级的含义是国际通用的标准，相同性能等级的螺栓，不管其材料和产地的区别，其性能是相同的，设计上只选用性能等级即可。 常用螺丝规格表

强度等级所谓级和级，是指螺栓的抗剪切应力等级为和，公称抗拉强度800N/MM2 公称屈服强度640N/MM2 一般的螺栓是用""表示强度的，，X*100=此螺栓的抗拉强度，，X*100*（Y/10）=此螺栓的屈服强度（因为按标识规定：屈服强度/抗拉强度=Y/10）。如级则此螺栓的抗拉强度为：400MPa 屈服强度为：400*8/10=320MPa 另：不锈钢螺栓通常标为A4-70，A2-70的样子，意义另有解释 度量 当今世界上长度计量单位主要有两种，一种为公制，计量单位为米（m）、厘米（cm）、毫米（mm）等，在欧州、我国及日本等东南亚地区使用较多，另一种为英制，计量单位主要为英寸（inch），相当于我国旧制的市寸，在美国、英国等欧美国家使用较多。 1、公制计量：（10进制） 1m =100 cm=1000 mm 2、英制计量：（8进制） 1英寸=8英分 1英寸= mm 3/8¢¢× = 3、1/4¢¢以下的产品用番号来表示其称呼径，如： 4#， 5#， 6#， 7#， 8#， 10#， 12# 螺纹 一、螺纹是一种在固体外表面或内表面的截面上，有均匀螺旋线凸起的形状。根据其结构特点和用途可分为三大类： （一）、普通螺纹：牙形为三角形，用于连接或紧固零件。普通螺纹按螺距分为粗牙和细牙螺纹两种，细牙螺纹的连接强度较高。 （二）、传动螺纹：牙形有梯形、矩形、锯形及三角形等。 （三）、密封螺纹：用于密封连接，主要是管用螺纹、锥螺纹与锥管螺纹。 二、螺纹配合等级： 螺纹配合是旋合螺纹之间松或紧的大小，配合的等级是作用在内外螺纹上偏差和公差的规定组合。（一）、对统一英制螺纹，外螺纹有三种螺纹等级：1A、2A和3A级，内螺纹有三种等级： 1B、2B和3B级，全部都是间隙配合。等级数字越高，配合越紧。在英制螺纹中，偏差仅规定1A和2A级，3A级的偏差为零，而且1A和2A级的等级偏差是相等的。 等级数目越大公差越小。 1、1A和1B级，非常松的公差等级，其适用于内外螺纹的允差配合。 2、2A和2B级，是英制系列机械紧固件规定最通用的螺纹公差等级。

开关电源通用技术规范要求

省广电有线信息网络股份分公司传输中心机房工程大容量高频开关电源 技术规书 二○一七年六月

目录 1.概述 (1) 1.1.定义 (1) 1.2.必须满足的技术标准/规 (3) 2.主要技术要求 (3) 2.1.系统规格 (3) 2.2.环境条件 (4) 2.3.系统总体 (4) 2.4.交流配电 (9) 2.5.整流模块 (10) 2.6.直流配电屏（不含高阻配电屏） (11) 2.7.监控模块 (12) 2.8.外观与结构 (14) 2.9.补充要求 (15) 2.10.节能环保 (18) 3.技术服务要求 (20) 3.1.设备检验 (20) 3.1.1.工程技术协调会 (20) 3.1.2.出厂检验 (20) 3.1.3.供货 (21) 3.1.4.到货检验 (21) 3.1.5.到货抽检 (22) 3.2.工程服务 (23) 3.2.1.安装调测服务（交钥匙工程） (24) 3.2.2.督导调测服务 (25) 3.2.3.督导服务 (25) 3.3.设备验收 (26) 3.3.1初验 (26) 3.3.2.试运行 (26) 3.3.3.终验 (27) 3.4.保修 (28) 3.4.1.保修期 (28) 3.4.2.设备巡检服务 (28) 3.4.3故障件修理 (28) 3.4.4.故障响应及技术支持服务 (29) 3.4.5备件供应 (31) 3.4.6.技术文件 (32) 3.4.7.软件补丁 (32) 3.4.8.特殊情况下的服务 (32) 3.4.9.电子文档提供服务 (33) 3.4.10.资料共享 (33) 3.5.技术培训 (33)

SPEC-USB2.0规范及测试标准

PRODUCT SPECIFICATION SPEC.NO. SPEC-USB 2.0 Approved Date 02-26-2001 Name PRODUCT SPECIFICATION Amended Date 05-29-2003 TYPE PLUG&RECEPTACLE Page 1 Sum To 8 Pages A&B Title USB2.0 １．SCOPE This specification covers performance, methods and quality requirements for Universal Serial Bus (USB) plug and receptacle connectors. These connectors are cable mounted plug and printed circuit board mounted receptacle connectors. 2. REQUIREMENTS 2.1 Design and Construction Product shall be of the design , construction and physical dimensions specified The in applicable product drawing. 2.2 Materials and Plating They are specified on applicable product drawing. 2.3 Ratings A.Voltage: 30 VAC (rms) B.Current: 1.5A per contact, not to exceed 30℃ temperature rise C.Operating temperature: -20℃ to +85℃ D.Storage temperature: -25℃ to +85℃ E.Nominal Temperature Rating: +20℃ 2.4 Test Requirements and Procedures Summary D Amended 05-29-2003Check Director Tab C Amended 10-17-2001 A Approved 02-26-2001 陈永飞 Description Date Item Change

(完整版)开关电源的用途

开关电源的用途 开关电源产品广泛应用于工业自动化控制、军工设备、科研设备、LED照明、工控设备、通讯设备、电力设备、仪器仪表、医疗设备、半导体制冷制热、空气净化器，电子冰箱，液晶显示器，LED灯具，通讯设备，视听产品，安防，电脑机箱，数码产品和仪器类等领域 开关电源的主要类型和分类 开关电源的主要类型 现代开关电源有两种：一种是直流开关电源；另一种是交流开关电源。这里主要介绍的只是直流开关电源，其功能是将电能质量较差的原生态电源（粗电），如市电电源或蓄电池电源，转换成满足设备要求的质量较高的直流电压（精电）。直流开关电源的核心是DC/DC转换器。因此直流开关电源的分类是依赖DC/DC转换器分类的。也就是说，直流开关电源的分类与DC/DC 转换器的分类是基本相同的，DC/DC转换器的分类基本上就是直流开关电源的分类。

直流DC/DC转换器按输入与输出之间是否有电气隔离可以分为两类：一类是有隔离的称为隔离式DC/DC转换器；另一类是没有隔离的称为非隔离式DC/DC转换器 隔离式DC/DC转换器也可以按有源功率器件的个数来分类。单管的DC/DC转换器有正激式（Forward）和反激式（Flyback）两种。双管DC/DC转换器有双管正激式（DoubleTransistor Forward Converter），双管反激式（Double Transistr Flyback Converter）、推挽式（Push-Pull Converter）和半桥式（Half-Bridge Converter）四种。四管DC/DC转换器就是全桥DC/DC转换器（Full-Bridge Converter）。 非隔离式DC/DC转换器，按有源功率器件的个数，可以分为单管、双管和四管三类。单管DC/DC转换器共有六种，即降压式（Buck）DC/DC转换器，升压式（Boost）DC/DC转换器、升压降压式（Buck Boost）DC/DC转换器、Cuk DC/DC转换器、Zeta DC/DC转换器和SEPIC DC/DC转换器。在这六种单管DC/DC 转换器中，Buck和Boost式DC/DC转换器是基本的，Buck-Boost、Cuk、Zeta、SEPIC式DC/DC转换器是从中派生出来的。双管DC/DC转换器有双管串接的升压式（Buck-Boost）DC/DC转换器。四管DC/DC转换器常用的是全桥DC/DC转换器（Full-Bridge Converter）。

通知的格式范文

通知的格式范文 一、通知的格式 通知是各种党和政府的部门、机关、单位向下级机关、部门、单位或工作人员传达上级指示，要求做什么事情时，所常使用的一种公文样式。同级对同级有什么事情需要告诉，有什么活动需要对方参加，主管部门也可以发通知。 通知的样式，在机关中常用的有如下五种：①会议的通知；②布置工作的通知；③交流情况或信息的通知；④转发请示、报告和意见的通知；⑤传达领导意见，任免干部，发布行政法规的通知。不论我们写哪一种样式的通知，在写作中都要把下列几项内容写清楚：被通知者的单位或个人名称或姓名，发出通知的目的和要求，通知的事项，发通知的单位名称和时间。（一）标题 写在第一行正中。可只写“通知”二字，如果事情重要或紧急，也可写“重要通知”或“紧急通知”，以引起注意。有的在“通知”前面写上发通知的单位名称，还有的写上通知的主要内容。如，“XXX关于XXX的通知” （二）称呼 写被通知者的姓名或职称或单位名称。在第二行顶格写。(有时，因通知事项简短，内容单一，书写时略去称呼，直起正文。但此种情况极少)。注，写被通知单位时可用全称也可用规范简称，但应注意保持意思明确避免歧义。针对此问题，应当多学习过往范文。 （三）正文 另起一行，空两格写正文。正文因内容而异。 1.开会的通知要写清开会的时间、地点、参加会议的对象以及开什么会，还要写清要求。 2.布置工作的通知，要写清所通知事件的目的、意义以及具体要求和作法。 3.周知有关事项的通知要语意明确言简意赅。 4.写通知一般采用条款式行文，可以简明扼要，使被通知者能一目了然，便于遵照执行。 （四）落款 分两行写在正文右下方，一行署名，一行写日期。二、会议通知格式（一）什么是会议的通知 会议通知是上级对下级、组织对成员布置工作、传达事情召开会议之前广泛应用的书面通知中的一种。 （二）怎样写好召开会议的通知 执笔人在写这种通知之前，要问清楚会议的详细内容。这些内容一般包括被通知的单位或个人，会议的名称，开会的时间、地点，要求参加会议者会前办什么事情等。此外，还应了解召开会议的目的，会议的有关要求。 一篇完整的会议通知，包括如下几部分： 1.标题。写在第二行中间，字略大一点。标题有三种写法：一是只写“通知”二字；二是紧急或重要事情，可以写成“紧急通知”或“重要通知”借以引起人们重视；三是把发文单位、名称、会议的主要内容和文种也写进去。 2.称呼。写被通知者的单位名称或者姓名，称呼的写法有两种：一种写在第二行或第三行，顶格写，称呼后面加冒号（：），【第二种方法在正式行文场合很少用，多为党政内部行文】另一种是写在正文的下面一行第三、四格，写“此致”二字，接着另起一行顶格写被通知者的单位和姓名，“此致”后不要加标点符号。这种通知，被通知者见通知后要在自己的名字后边写一个“知”字，重要的会议多用此种通知方法。“此”，这，指“通知”，“致”，给与送达。 3.正文。从标题下第二行，空两格写通知的内容，这是通知的主要部分。召开会议的通知要把开会的时间、地点、什么人参加、开什么会、会前要做好哪些准备工作等内容写清楚。如

开关电源的主要技术指标知识

开关电源的主要技术指标知识 开关电源以其低功耗、高效率、小体积等显著优点而深受人们的青睐，并被广泛应于 计算机设备、电子仪器、通信设备和家用电器中。开关电源的主要技术指标知识： 第一、输出电压的纹波：由于开关电源的稳压过程是一个不断取样反馈调节的过程，因此在输出的直流电压上会出现一个叠加的波动的纹波电压，即输出的纹波电压。这 个值越小，表示输出特性越好。纹波有两种表示方法：一是输出纹波电压有效值;二是输出纹波电压的峰峰值。一般开关电源的规格都要求小于输出直流电压的1%，其频 宽为20Hz-20MHz或者其他更高频率，如100MHz等。开关电源在恶劣环境下，其输 出直流电压加上杂讯纹波后的输出瞬时电压，应不超出输出高低电压界线(Min值和Max值)，否则将可能会导致电源电压超过或者低于逻辑电路(如TTL电路)的工作电压而误动作，进一步造成死机现象。 第二、电压调整率：电压调整率也称为电压稳定度，是在输出电流不变(即负载不变化)，而输入的交流工作电压变化时，输出电压的相对变化量。此项技术指标用来验证开关电源在最恶劣的电源电压环境下，输出电压的稳定度是否符合需求规格。 第三、输入电压范围：当开关电源的输入电压发生变化时，保持输出特性不变的输入 电压变化范围。这个范围越宽，表示电源适应外界的市电变化的能力越强，开关电源 的工作范围就越宽。它和开关电源内部的误差放大器、取样反馈调节电路的增益及占 空比调节范围有关。目前开关电源的输入电压变化范围已经做到90V-270V,可以省去 许多电器上的110V/220V转换开关。 第四、转换效率：电源输出功率与输入功率的比值。这个比值越高，表示变化效率高，开关电源的体积越小，可靠性也越高。目前开关电源的效率可达到90%以上。 第五、输出内阻：输出电压的变化量与输出电流的变化量的比值。这个比值越小，表示电源输出电压随负载大小的变化越小，稳压性能好。

开关电源芯片通用测试要求和步骤-antonychen

开关电源芯片通用测试要求和步骤 By Antony Chen 开关电源必须通过一系列的测试，使其符合所有功能规格、保护特性、安规（如UL、CSA、VDE、DEMKO、SEMKO，长城等之耐压、抗燃、漏电流、接地等安全规格）、电磁兼容（如FCC、CE等之传导与幅射干扰）、可靠性（如老化寿命测试）、及其他特定要求等。 测试开关电源是否通过设计指标，需要各种精密的电子设备去模拟电源在各种环境下实际工作中的性能。 一、理论上的DCDC测试指标清单 1.描述输入电压影响输出电压的几个指标形式（line） 1.1绝对稳压系数：K=△Uo/△Ui 1.2相对稳压系数：S=△Uo/Uo / △Ui/Ui 1.3电网调整率（也称线性调整率）： 它表示输入电网电压由额定值变化+-10%时，稳压电源输出电压的相对变化量，有 时也以绝对值表示。 line reg=△Uo/Uo*100%@ -10%

【精品】第六讲：开关电源新技术

第六讲：开关电源新技术 这里所说的新技术，是 指最近20年内发展起来的技 术内容,涉及开关电源的效 率、动态响应、功率因数等概 念. 1．1、软开关技术 开关管的损耗一直是开关变换器设计中的一个核心问题。要减小开关电源的体积，降低输出电压纹波，提高开关频率是最直接有效的方法，但开关管的损耗正是限制开关频率提高的最大原因，开关管在导通或关断状态下的损耗（称为通态损耗和断态损耗）是比较小的，但在导通和关断动作过程中的损耗（称为导通损耗和关断损耗，即开关损耗）非常大,因为在这时开关管要同时承受高电压和大电流。开关频率越高,开关损耗就越严重。要降低开关损耗就必须从控制开关管的开关过程着手，使开关管上不能同时出现高电压和大电流。传统的缓冲器（Snubber）电路（常用的电路，主要是保证开关管安全工作）,能减小一些开关损耗，但程度非常有限而且又引入了缓冲电路的损耗.给出一个典型的缓冲电路的形式（图3）,图中虚线框内部分为缓冲器电路。

谐振（Resonant）的方法是能够大幅度降低开关损耗的方法。谐振概念的产生比较早，广泛用于机械工业的中频感应加热炉其实就是一个利用负载产生谐振的例子。但谐振的方法用于直流变换器则是在上世纪80年代才有较大的发展，首先建立起了零电压开关ZVS（ZeroVoltageSwitch)和零电流开关ZCS（ZeroCurrentSwitch）的概念，其基本思路是使开关管的电压或电流与外部谐振回路产生谐振，从而使开关管可以在零电压状态导通或是在零电流状态下关断。这种方法的困难在于保证开关管的零压或零流条件（不同输电压和不同负载条件入），为解决这一问题发展了准谐振变换器QRC(QuasiResonantConverter)的技术，也有ZVS—QRC和ZCS-QRC两类。 谐振方式的变换器最突出的优点就是极大地降低了开关损耗,使变换器的工作频 率提高到了MHz量级的水平，适合 在一些对体积和重量要求极为严 格的场合(比如飞行器）中使用。 谐振技术另一个突出的应用是移 相全桥(PhaseShiftFull—Bridge) 的线路，该线路中,谐振概念与移相PWM控制的方法巧妙结合，消除了谐振方式固有的缺陷，因而在通信等中大功率场合被广泛采用.除此之外，谐振方式则因器件电压电流应力过大、难以保证零开关条件、难以与PWM方式配合等原因不能得到普遍应用。 上世纪90年代出现的零电压转换ZVT（ZeroVoltageTransition）和零电流转换

PACKSPEC 产品包装技术条件 REV2

1.0 目的 加强本公司出厂产品包装与标识的管理。 2.0 适用范围 本标准依据GB/T13384《机电产品包装通用技术条件》，规定了高、低压开关柜产品的包装通用技术要求；包装标志与随机文件。适用于本企业高、低压开关柜包装。 3.0 参考文件 GB/T13384 机电产品包装通用技术条件 GB191 包装储运图示标志 GB349 一般用途圆钢钉 GB738 阔叶树材胶合板 GB2934 联运平托盘外部尺寸系列 GB4857 运输包装件基本试验 GB4892 硬质直方体运输包装尺寸系列 GB5398 大型运输包装件试验方法 GB6388 运输包装收发货标志 4.0名词定义（略） 5.0 相关方与职责 5.1 包装供应商按要求对产品实施包装与标识。 5.2 物料部负责包装，且对包装箱及其内容进行标识。 5.3 生产部提供待包装产品、附件及清单。 6.0 作业程序 6.1 选用材料 6.1.1.包装用木材应在保证包装箱强度条件下，合理用材适当选用树种。主要受力构件应以 落叶松、马尾松、紫云杉、白松、榆等木材为主，也可采用与上述木材物理、机械性 能相近的其他树种。 6.1.2.同一包装箱的箱板色泽、宽度应基本一致，外表面应平整，无明显毛刺和虫眼（已修 补例外）。 6.1.3.箱体底板框架及侧板框架应选用硬度适中的、不低于建筑结构用木材标准的方木。当 柜体总重量低于2.5吨时，此方木不小于50mm×75mm，大于2.5吨时，应不小于75mm

×100mm。 6.1.4.箱体底板、箱体侧面及顶部的加固支撑件应选用与上述要求一致的厚度不小于20mm的 木板。 6.1.5.箱体的各个侧面、底板和顶部应选用厚度不小于9mm的木夹板。 6.1.6.选用在38°和90%相对湿度中，水蒸气传导率为0.05GB/SQR.M/24小时的真空铝膜。 6.1. 7.选用1.0mm光滑泡沫聚乙烯片。 6.1.8.选用厚度不小于0.5mm的塑料袋。 6.1.9.选用符合中国国家标准的螺栓、螺母、垫圈和其他紧固件（包括气枪钉）。 6.1.10.密封橡胶垫圈的厚度应不小于2mm。 6.1.11.铁皮表面应光滑，不生锈。 6.2 包装要求 6.2.1木箱包装要求 6.2.1.1产品包装前需经检验合格，即在产品的正面（正常操作面）贴有“OK”标志后方可装 箱。 6.2.1.2在底板上需覆盖至少两层1.0mm光滑泡沫聚乙烯片，紧固螺孔处应放置橡胶垫圈。泡 沫聚乙烯片、橡胶垫圈和紧固螺栓之间用501胶水粘合以保证其真空度。 6.2.1.3所有开关柜应选用M12、8.8级螺栓紧固于底板上，并用橡胶垫圈密封。用经泡沫聚乙 烯片包裹的木质挡块阻隔于两个柜体顶部之间，以防止柜体移动和相互碰撞。底板开 固定螺栓孔处应有木方加固以保证底板强度。产品应垫稳、卡紧、压紧固定于包装箱 内。做好安全防护措施，不允许有任何相对移动的可能，以确保产品的安全，稳妥及 完整无缺。 6.2.1.4产品中易碎、凸出的设备和元件部分，如仪表、玻璃盖等物均应用泡沫聚乙烯片和轧 制瓦楞纸适当保护，并用胶带或捆扎塑料薄膜固定这些包装材料。固定胶带不能直接 接触开关柜表面，以免留下难于清除之痕迹。 6.2.1.5产品中易碎和松动的部件，以及靠重力动作的触点等，装箱前应用线绳扎牢，以保证 适合于陆路及水路运输及装载要求。 6.2.1.6首层应先用泡沫聚乙烯片固定于底板后用塑料薄膜缠绕。塑料薄膜从柜体的下部至上 部缠绕，前后二道薄膜边缘重叠。 6.2.1.7第二层如需真空包装，则选用真空铝膜，采用热熔枪和真空泵进行包装。如为非真空 包装，应选用厚度不小于0.5mm的塑料袋进行包装。每一柜体内均需放置干燥剂一包。 保证包装的防漏、防潮。 6.2.1.8第三层用塑料捆扎薄膜卷绕于第二层外，缠绕要求同6.2.2.6。 6.2.1.9产品不应与外包装箱直接接触，与箱体的端面之间应留不小于125mm的空隙，与箱的 内侧面应留不小于75mm的空隙，以免碰损或撞毁。 6.2.1.10木箱整体包装完后，应在相应部位加铁皮固定。例如四个顶角、箱体四条边线的1/2