Network Working Group L. Andersson, Ed. Request for Comments: 4929 Acreo AB BCP: 129 A. Farrel, Ed. Category: Best Current Practice Old Dog Consulting June 2007 Change Process for Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Protocols and Procedures
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF’s (G)MPLS
working groups’ responsibility for the (G)MPLS protocols. This
document is directed to multi-vendor fora and Standards Development
Organizations (SDOs) to provide an understanding of (G)MPLS work in
the IETF and documents the requisite use of IETF review procedures
when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes.
Andersson & Farrel Best Current Practice [Page 1]
Table of Contents
1. Introduction (3)
1.1. Document Source (4)
1.2. Conventions Used in This Document (4)
2. Overview of (G)MPLS within the IETF (4)
2.1. IETF Working Groups Developing (G)MPLS Technology (5)
2.1.1. Multiprotocol Label Switching Working Group (5)
2.1.2. Common Control & Measurement Plane Working Group (5)
2.1.3. MPLS and CCAMP Division of Work (6)
2.2. Other (G)MPLS Technology-Related Working Groups (6)
2.3. Organizations Outside the IETF (7)
3. Overview of (G)MPLS Change Process (8)
4. MPLS and GMPLS Change Process (9)
4.1. Flow Diagram (10)
4.2. Description of Process Stages (11)
4.2.1. Preliminary Investigation (12)
4.2.2. Requirements Statement Evaluation (13)
4.2.3. Working Group Procedures (14)
4.2.4. REWG Evaluation of the Requirements Statement I-D ..14 4.2.
5. AD Evaluation of Completed Requirements
Statement I-D (14)
4.2.6. IESG review of Requirements Statement I-D
and PSWG Charter (15)
4.2.7. Solutions Work (15)
5. Rejecting the Requirements Statements I-D (16)
5.1. Reasons for Rejection (16)
5.2. Actions Required When Rejecting Requirements
Statement I-Ds (18)
5.3. Appeals (18)
6. Abandonment of the Solutions I-D (19)
6.1. Appeals (19)
7. (G)MPLS Integrity and Ownership (19)
8. Security Considerations (20)
9. Acknowledgements (20)
10. IANA Considerations (21)
11. References (21)
11.1. Normative References (21)
11.2. Informative References (21)
Andersson & Farrel Best Current Practice [Page 2]
1. Introduction
The MPLS and GMPLS technology is developed in two main tracks in the IETF. "MPLS" refers to the work done for packet switched networks,
while "GMPLS" refers to the efforts to apply the MPLS protocols to
all types of networks including packet and non-packet technologies.
Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" is used in this document to indicate both of these tracks. A
terminology section that covers the use of terms and concepts used in this document is found in Section 2.6.
[RFC4775] discusses procedural issues related to the extension or
variation of IETF protocols by other SDOs. It provides the
guidelines and procedures to be used by other SDOs when considering
the requirements for extensions to IETF protocols. [RFC4775]
recommends that major extensions to, or variations of, IETF protocols only take place through normal IETF processes or in coordination with the IETF.
The (G)MPLS protocol families were developed within the IETF and
constitute significant protocol suites within the Internet standards. The (G)MPLS suites of protocols have become popular for a number of
new applications and deployment scenarios. There have been concerns with regards to other technology fora developing, using, and
publishing non-standard protocol extensions as a standard not only
for use within their community, also for wider use by the industry.
Especially concerning is the development of extensions, without
consulting the (G)MPLS working groups, which are in conflict with
efforts on-going in the (G)MPLS working groups, and then presented to the (G)MPLS working group as ’fait accompli’.
The definition and publishing of non-standard extensions by other
fora, without IETF review, and outside of the IETF publication
process, regardless if rationalized as limited to use among fora
vendors, or limited to a particular application, or rationalized as
allowing timely demos, has the unfortunate potential to hinder
interoperability and increase complexity of the protocol, sows
confusion in the industry, and circumvents the Internet standards
process that exists to ensure protocol implementability. As
described in [RFC4775], non-standard extensions, including
experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards
body.
This document clarifies the IETF’s MPLS and Common Control and
Measurement Plane (CCAMP) working groups’ roles and responsibilities for the (G)MPLS protocols and documents the requisite use of, and how Andersson & Farrel Best Current Practice [Page 3]
to apply, the [RFC4775] procedure of using the IETF review processes, [RFC2026] and [RFC2418], for fora wishing to apply or extend the
(G)MPLS protocols. Use of the IETF review processes will ensure an
open process for protocol development and ensure a non-harmful
evolution for these IETF protocols, which will benefit the larger
industry users’ community. IETF itself cannot enforce a forum to use the (G)MPLS change procedure, though any forum not following it, when applying for IANA assignment or IETF publication, will be delayed
until this procedure has been completed.
This document does not change the formal IETF standards process as
defined in [RFC2026] and [RFC2418]. It is consistent with the
general procedures for protocol extensions defined in [RFC4775] and
shows how they are applied in the case of (G)MPLS. Any procedures
described in this document are to be implemented in a way consistent with these three documents. They MUST be used when other SDOs and
fora wish to propose (G)MPLS changes. They SHOULD be used internally within the IETF unless the changes concerned are considered non-
controversial by the responsible Area Director(s) (e.g., covered by
the working group charter), in which case other aspects of the normal IETF standards process cover the necessary procedures.
1.1. Document Source
This document is the joint work of the IETF Routing Area Directors,
the IETF MPLS and CCAMP Working Group Chairs, and the IETF’s liaisons to the ITU-T. It had considerable review and comment from key
members of the ITU-T who have given their time and opinions based on experience for which the authors are grateful. The IESG has also
provided valuable input to arrive at the process documented here.
The acknowledgements section lists those whose contributions have
been particularly helpful.
1.2. Conventions Used in This Document
Although this document is not a protocol definition, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119 [RFC2119]. This usage is chosen to make the steps and procedures completely clear.
2. Overview of (G)MPLS within the IETF
This section describes the key IETF working groups developing the
(G)MPLS technology and provides information on IETF working groups
using the (G)MPLS technology.
Andersson & Farrel Best Current Practice [Page 4]
It should be remembered that the IETF environment is highly dynamic. Working groups and whole areas come and go. The overview of the
relevant working groups within the IETF is only a snapshot in time. 2.1. IETF Working Groups Developing (G)MPLS Technology
Two working groups in the IETF’s Routing Area are responsible for
work related to developing the (G)MPLS technologies: Multiprotocol
Label Switching (MPLS) working group and the Common Control and
Measurement Plane (CCAMP) working group.
The following sections provide brief overviews of the chartered work of these two IETF working groups.
2.1.1. Multiprotocol Label Switching Working Group
The Multiprotocol Label Switching (MPLS) working group is responsible for standardizing the base technology that uses label switching, and for describing the implementation of Label Switched Paths (LSPs) over various packet and frame-based link level technologies. The working group charter includes procedures and protocols for the distribution of labels between routers, as well as encapsulations, operation and
management, traffic engineering, and multicast considerations.
This document assumes that the MPLS working group remains the
chartered authority on MPLS technologies, but notes that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols. Further, in the event that
the MPLS working group completes its work and is closed, the IETF
will use the non-working group standards track document process
(described in [RFC2026]) using designated experts from the community [RFC2434] for the MPLS protocols.
2.1.2. Common Control & Measurement Plane Working Group
The IETF Common Control and Measurement Plane (CCAMP) working group
coordinates the work within the IETF defining common control and
measurement planes for ISP and SP core tunneling technologies. This includes, but is not limited to, defining signaling protocols and
measurement protocols such that they support multiple physical path
and tunnel technologies using input from technology-specific working groups such as the MPLS working group. It also includes the
development of protocol-independent metrics and parameters for
describing links and paths that can be carried in protocols.
The technology that the CCAMP working group focuses on is called
Generalized MPLS (GMPLS), indicating that CCAMP addresses a
generalized technology, where labels are defined in such a way that Andersson & Farrel Best Current Practice [Page 5]
they will be compatible with the technology over which the data is
transported. While the MPLS working group focuses on packet- and
frame-switched technologies, the CCAMP working group work focuses on common methods across a broad spectrum of switching technologies
including packet and frame technologies. In this respect, GMPLS can be viewed as a superset of MPLS.
The procedures in this document assume that the CCAMP working group
remains the authority on GMPLS technologies, but acknowledges that
the IETF may appoint another working group (refer to [RFC2418]) to
handle specific extensions or changes to the protocols. Further, in the event that the CCAMP working group completes its work and is
closed, the IETF will use the non-working group standards track
document process (described in [RFC2026]) using designated experts
from the community [RFC2434] for the GMPLS protocols.
2.1.
3. MPLS and CCAMP Division of Work
From time to time, the MPLS and CCAMP working groups decide to divide work between themselves in a way that does not strictly follow the
split between the working groups as defined in the working group
charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS
working group is specifying requirements and base technology for all of the (G)MPLS technologies.
An entity or individual that wishes to propose extensions or changes to (G)MPLS should first decide to which working group (MPLS or CCAMP) it will bring the proposal. However, the MPLS and CCAMP working
group chairs, in conjunction with their Area Directors, may redirect the proposal to another working group.
2.2. Other (G)MPLS Technology-Related Working Groups
Problem statements and requirements for (G)MPLS technology have been produced by several working groups in addition to the MPLS and CCAMP working groups. IETF working groups are defined for the management
of specific tasks by their charter. Their charter defines their
role, relationship with other working groups, and the applicable
procedures to follow when extensions to (G)MPLS may be needed. This section provides an overview of the (G)MPLS-related groups and their responsibilities. Additional information describing the working
groups and their charters is available on the IETF web pages.
The IP over Optical (IPO) working group and the Internet Traffic
Engineering working group (TEWG) are examples of working groups which focus on problem statements and requirements for (G)MPLS to be
considered by the (G)MPLS working groups. These working groups have not specified any protocols.
Andersson & Farrel Best Current Practice [Page 6]
The Bidirectional Forwarding Detection (BFD) working group, also may use the (G)MPLS protocols and mechanisms. The BFD working group is
chartered for requirements evaluation and protocol specification
related to BFD. If the working group needs to extend or change the
(G)MPLS protocols, the procedures specified by its charter and the
IETF’s standard processes are applicable.
The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have
been chartered to specify a limited number of solutions for Provider Provisioned VPNs. Both working groups are in the Internet Area.
Much of the work of the L2VPN and L3VPN working groups does not
include specifying new protocols or extensions to existing protocols. Where extensions are needed, the procedures as specified by their
charters and the IETF’s standard processes are applicable.
The Layer 1 VPN (L1VPN) working group is chartered to specify
mechanisms necessary for providing Layer 1 VPN services
(establishment of layer 1 connections between CE devices) over a
GMPLS-enabled transport service-provider network. Protocol
extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the L1VPN working group will not develop GMPLS protocol
extensions in isolation, but will develop requirements and propose
extensions that will be reviewed and approved by the (G)MPLS working groups.
The Pseudo Wire Emulation End to End (PWE3) working group is a
working group that may use the (G)MPLS protocols in its
specifications. Should the PWE3 specifications require extension or changes to the (G)MPLS protocols, the procedures as specified by its charter and the IETF’s standard processes are applicable.
2.3. Organizations Outside the IETF
A number of standards development organizations (SDOs) and industrial forums use or reference the (G)MPLS protocols in their
specifications. Some of these organizations have formal or informal liaison relationships with the IETF [RFC4052]. The IETF exchanges
information with these organizations about what is happening on both sides, including plans and schedules, using liaison statements
[RFC4053]. More details about the cooperation relationship between
the IETF and the ITU-T can be found in [RFC3356].
The procedures in this document are applicable to all organizations
outside the IETF whether or not they have formal liaison
relationships with the IETF. If any organization outside the IETF
has a requirement for extensions or modifications to the (G)MPLS
protocols then the procedures in this document apply.
Andersson & Farrel Best Current Practice [Page 7]
3. Overview of (G)MPLS Change Process
This is a non-normative section, as it is intended to provide a high- level view of [RFC4775] procedures for protocol extensions.
Application of these procedures for (G)MPLS are defined in detail in Section 4.
Whenever there is reason to believe that a particular problem may be solved by use of or extensions to the (G)MPLS protocols, a
communication using the formal liaison process, or, for a forum
without a formal relationship, an informal communication, may be used to discuss the problem with the IETF ([RFC4052] and [RFC4053]).
Collaboration with the IETF in the early discussion phase will
facilitate a timely understanding of whether the problem has already been solved, may be outside the scope of the (G)MPLS protocols, or
may require more investigation.
Whenever any extension or change to the (G)MPLS protocols is desired, a problem statement and/or requirements statement must be produced
and must be submitted to IETF as an Internet-Draft. When the
requirements come from an external organization, informal
communications, such as e-mail to working group mailing lists, is
strongly encouraged as it facilitates timely and cooperative work.
However, if desired, the Internet-Draft, containing the
requirement(s), may be submitted to the working group using a formal liaison statement. IETF’s response to the request will be given as a reply to the liaison. This use of formal communication reduces the
risk of confusing an individual participant’s opinion for that of the group as can happen on mailing lists, though it does introduce a more lengthy communication cycle. If there is no formal liaison
relationship, a communication may be sent directly to the (G)MPLS
working group, a relevant Area Director, or the IESG.
The IETF, through the appropriate Area Director, and the chairs of
the MPLS and CCAMP working groups for (G)MPLS related work, will
direct the requirements draft to an appropriate working group for
assessment and comment. This process may require communication and
discussion for clarification, but the IETF undertakes to perform the assessment in a timely manner.
In assessing the requirements statement I-D, the IETF may determine: - that the requirements can be satisfied without modifications to the (G)MPLS protocols
Andersson & Farrel Best Current Practice [Page 8]
- that the requirements are not sufficiently general or there is not sufficient interest to do a standards-track solution to warrant a
Standards-track change to the (G)MPLS protocols
- that the requirements justify a standards-track change to the
(G)MPLS protocols
- that the requirements might not be possible to satisfy without
violating the (G)MPLS architecture in a way that would harm the
(G)MPLS technology
- that the requirements should be combined with other requirements to solve a more general problem or solve the same problem in a more
flexible way.
In the event that the IETF agrees to develop a solution, the IETF
will set milestones that would result in timely delivery of the
solution in a timely manner. If the IETF rejects the requirements,
this will only be done with clear explanation and full discussion
with the source of the requirements.
The solutions that are developed within the IETF may be sourced from external organizations and presented for review, discussion,
modification, and adoption as Internet-Drafts. Such solutions drafts may be presented to the IETF in advance of the completion of the
requirements work, but all solutions will be processed through the
normal IETF process with other proposed solutions. Solution drafts
are adopted as an IETF working group draft when the requirements are stable, and not before the protocol-responsible working group has a
charter item to cover the solutions work. It is strongly recommended for interested parties to start informal discussion in the IETF, as
early as possible, and to co-author in the IETF’s work. It is not
recommended for the source forum to continue to work on solutions in parallel with on-going work in the IETF. If the protocol-responsible working group is unable to accept the work (e.g., due to current work load), the IETF processes ([RFC2418]) provide alternate options for
ensuring the work is completed.
4. MPLS and GMPLS Change Process
This section defines the (G)MPLS change process and the rules that
must be followed in order to make extensions or changes to the
(G)MPLS protocols. The language of [RFC2119] is used in order to
clarify the required behavior of the IETF and the originator of the
change request. It is consistent with the general procedures for
protocol extensions defined in [RFC4775]. Any interpretation of
procedures described in this document and their implementation are to be in a way consistent with [RFC4775].
Andersson & Farrel Best Current Practice [Page 9]
Anyone who intends to use one of the existing (G)MPLS protocols, but thinks that it will not satisfy their needs MUST use the procedures
described in this document. They SHOULD be used internally within
the IETF unless the changes concerned are considered non-
controversial by the responsible Area Director(s) (e.g., covered by
the working group charter), in which case other aspects of the normal IETF standards process apply. Changes or extensions to the (G)MPLS
protocols MUST NOT be made by any other mechanism. The IETF MUST NOT endorse any publications (including RFCs, whether on the Standards
Track, Informational, or Experimental) that change or extend the
(G)MPLS protocols except for those that arise through the correct
execution of the procedures in this document. The IETF MUST NOT
endorse any IANA action that allocates (G)MPLS protocol codepoints,
except as a result of actions arising from the correct execution of
the procedures in this document.
4.1. Flow Diagram
Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS requirements evaluation working group (REWG) and (G)MPLS protocol
solutions working group (PSWG). The figure presents two alternatives for a requestor: (1) contact the IETF early in the problem definition phase (preliminary investigation), or, (2) later, with a requirements statement. The figure is for illustration only; it does not contain all of the possible interactions and IETF procedure alternatives.
The text in the subsequent sections describes the process.
Andersson & Farrel Best Current Practice [Page 10]
Start +-------------+
| |optional |
+--<--------------------|preliminary |<-------Start
| |investigation|
V +-------------+
+------------+ +---------+ +---------+
|requirements| discussion |review by| YES | IESG | YES
|statement |----------->|WG chairs|------------->|decision |------+ |I-D | on mailing |and ADs | request to | | | +------------+ list +---------+ IESG to +---------+ | | appoint REWG | | |NO and charter |NO REWG| V req eval | chartered| +-------------+ | to work on| |response | | requirements| |to the | | statement| |requirements |<-----------------+ | +->|statement |<----------------+ | | +-------------+ | | | ^ | | NO| | NO | | | +-----------------+ | V | | | NO +------+ +--------+ +-------+ +--------| REWG | | IESG/ | YES | AD | | req | +-----------|decision|<---------------|review |<------------| eval | |PSWG | | request to | | YES | | |chartered +--------+ IESG to +-------+ +------+ |to work approve I-D
| and charter
| PSWG (if needed)
| +---------+
| | IETF | +-----+
+--------->| PSWG |-----/ /---->| RFC |
+---->| process | +-----+
| +---------+
solutions
I-D
Figure 1: Change Process Overview
4.2. Description of Process Stages
This section describes how the (G)MPLS change process works, what is expected from individuals or organizations that want to extend or
change the (G)MPLS protocols, and the responsibilities of the IETF. Andersson & Farrel Best Current Practice [Page 11]
4.2.1. Preliminary Investigation
This step is OPTIONAL, and is intended to provide a lightweight way
to "feel out" the IETF’s position on a proposal without going to the effort of writing an Internet-Draft. The intention is to determine
whether the problem has been examined already, whether the problem is in scope for the IETF, and whether solutions are already known.
Although the preliminary investigation phase is optional it is
RECOMMENDED that the originator of any requirements consult and
discuss the issues concerned as early as possible to avoid any wasted effort, and the preliminary investigation phase provides a mechanism to do this.
Useful discussions may be held at this stage in order to ensure that the problem statement and requirements statement Internet-Drafts
contain the right material. This step is described as lightweight
because no Internet-Draft is required and because the step largely
involves offline discussions. However, it may be the case that this step involves considerable technical discussions and may, in fact,
involve an extensive, substantive exchange of ideas and opinions.
This step SHOULD be carried out informally on the mailing list of the REWG or on the Routing Area discussion mailing list, and MAY be
initiated by any individual, group of individuals, external
organization, or IETF working group.
When an external SDO has a liaison relationship with the IETF, it MAY carry out this step using a formal liaison. The liaison SHOULD be
sent to the designated liaison manager who is responsible for
forwarding them to the IESG who will assign a Responsible AD. The
initiators of the liaison SHOULD make themselves available for
discussion on the selected mailing list. If a formal liaison is
used, the IETF will respond using the procedures of [RFC4053].
At this stage, a problem statement I-D MAY be produced to help
further the discussions and to clarify the issues being addressed.
A possible outcome of this preliminary investigation is that the
requirements and problem are understood, but agreed to be out of
scope for the IETF. Alternatively, it may be that the problem can be solved with existing protocols. The full list of outcomes from the
preliminary investigation phase are similar to those for the
requirements statement evaluation phase described in Section 4.2.2,
but the requirements statement evaluation phase that allows wider
IETF community participation in developing a complete requirement set MUST form part of the process if the IETF is to consider to develop
protocol solutions. The process cannot move direct from the Andersson & Farrel Best Current Practice [Page 12]
preliminary investigation phase to the development of solutions
unless the working group agrees (e.g., the problem is minor).
4.2.2. Requirements Statement Evaluation
Before the IETF can formally pronounce on requests to change or
extend the (G)MPLS protocols, a requirements statement I-D MUST be
written per [RFC2026].
The requirements statement I-D MUST be introduced by the authors to
the IETF through an email to the REWG mailing list, to the Routing
Area discussion mailing list, or by a formal liaison from an external SDO which will result in the IETF introducing the requirements
statement I-D to the REWG mailing list. If the requirements
statement I-D is brought to the IETF through a formal liaison, the
initiators of the liaison SHOULD make themselves available for
discussion on the designated IETF mailing lists.
After discussion on the IETF mailing lists, the responsible Area
Director MUST decide whether the requirements will be formally
evaluated by the IETF, and MUST deliver a response to the per
[RFC4053] and [RFC4775]. If a formal liaison was not used, the
response SHOULD be delivered to the appropriate contact as listed on the communication.
The IETF response MUST be sufficiently explanatory to inform the
requesting organization of what, if anything, the IETF has decided to do in response to the request. The following list is provided to
illustrate possible responses:
a. Requirements not understood. Further discussion is required.
b. Requirements understood, but judged to be out of scope for the
IETF. In this case, the originator of the requirements can work on requirements and solutions and will not be impeded by the
IETF. The IETF may request to be kept informed of progress.
c. Requirements understood, but no protocol extensions are neede
d.
It may be desirable for the external SDO to cooperate with the an IETF working group in the production of an Applicability
Statement Internet-Draft.
d. Requirements understood, and the IETF would like to develop
protocol extensions. This results in execution of the rest of
the procedure, described below. The requirements raised in the
requirements statement I-D may be combined with other
requirements to produce more general extensions or changes to the (G)MPLS protocols.
Andersson & Farrel Best Current Practice [Page 13]
4.2.3. Working Group Procedures
In many cases, the problem covered by the requirements statement I-D will fall within the scope of the existing charter of a working
group. In this case, the responsible Area Directors will designate
the working group as the REWG and pass the requirements statement I-D to the working group for evaluation. If the problem is not covered
by an existing charter, other alternatives (refer to [RFC2418]) may
be used, e.g., rechartering, BOF, chartering a new working group.
If the IETF modifies its prior decision to accept the work, the IETF MUST communicate this to the requestor in a timely manner.
4.2.4. REWG Evaluation of the Requirements Statement I-D
The objective of the REWG evaluation process is to determine a clear and complete statement of the requirements for changes or extensions to the (G)MPLS protocols. This will necessitate normal IETF working group procedures in the REWG and MAY include the generation of
revisions of the requirements statement I-D in cooperation between
the members of the REWG and the original authors of the requirements statement I-D.
The originators of the requirements statement I-D MUST make
themselves available to discuss the work on the REWG mailing list.
If this does not happen, the chairs of the REWG MAY determine that
there is insufficient support for the work and MAY reject the
requirements statement I-D.
The output of the REWG will be either:
- a completed requirements statement I-D that has been accepted by
working group consensus within the REWG and has passed through
working group last call;
or
- a rejection of the requirements using the response procedure as
described in Section 5.
4.2.
5. AD Evaluation of Completed Requirements Statement I-D
As with all Internet-Drafts produced by a working group, the ADs will review the completed requirements statement I-D produced by the REWG. The ADs will then pass the document to the IESG for review. If
charter changes are needed or a new PSWG needed, the appropriate
process will be followed.
Andersson & Farrel Best Current Practice [Page 14]
4.2.6. IESG review of Requirements Statement I-D and PSWG Charter
As with all Internet-Drafts, the IESG will review and make a decision on the progression of the requirements statement I-D.
If the IESG rejects the requirements statement I-D, it will generate an appropriate response to the working group (and, if needed, to the originator of the request).
The IESG will review any proposed charter changes for the PSWG or, if needed, consider alternatives. This might include the formation of a new working group specifically to work on the solutions.
4.2.7. Solutions Work
The appropriate PSWG will start work on solutions following the
normal IETF process.
Solutions I-Ds MAY be prepared externally (such as within an external organization) or within the IETF, submitted to the IETF for draft
publication using the procedures of [RFC2418], and introduced to the PSWG for consideration. Such I-Ds MAY be submitted at earlier stages in the process to assist the REWG in its development and discussion
of the requirements, but no I-D will be formally considered as a
solutions I-D until the PSWG has a charter item that covers the work and the REWG chairs are confident that the requirements are stable.
The IETF makes no guarantees that an externally produced solutions
I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST consider such an I-D for review and revision as a possible solution
I-D, using the same open procedures ([RFC2418]) as for any individual submission. The IETF’s procedures are based on open and fair
participation, and thorough consideration of technical alternatives. Interested parties (both implementers and users) of the SDO
originating the request are strongly encouraged to participate in the PSWG to ensure appropriate interest is shown in the solutions work
and to provide timely solutions development. The IETF’s work, as
that of any SDO, is driven by its participants. The IETF is an open community and any SDO requesting IETF solutions work SHOULD ensure
appropriate industry interest in the work, or the IETF MAY
discontinue its support of the work. Appropriate communication of
the discontinued work will be made to the originator of the request
(if the originator is reachable).
The final development of the solutions I-D is subject to the normal
working group review, consensus, and last call within the PSWG. Andersson & Farrel Best Current Practice [Page 15]
Where the requirements originated from an external organization, the PSWG SHOULD regularly communicate its progress using a formal liaison process if one exists. This communication SHOULD also be used to
request review input and comment on the development of the solutions I-D. The solutions I-D MUST be communicated to the originating
organization during working group last call for final review against the requirements. When the solutions I-D is complete (normally upon completing working group last call and/or on entering the RFC
Editor’s queue) the PSWG MUST inform the originating organization of the completed solution.
5. Rejecting the Requirements Statements I-D
Rejection of the requirements statements is a sensitive matter for
the authors of the requirements and MUST be handled with full
disclosure and explanation by the IETF. All working group actions
are taken in a public forum ([RFC2418]).
The requirements can be rejected at various stages of the process as described in the previous sections. The person or group that makes
the rejection is responsible for generating an explanation of the
rejection and MUST follow the [RFC4775] process. Possible reasons
for rejection are described in this section.
5.1. Reasons for Rejection
The requirements statement I-D can only be rejected with full
disclosure by the IETF. Possible reasons for rejection and possible next steps as described here.
- Requirements not understood. Either during preliminary
investigation or during evaluation of the requirements statement
I-D, it was not clear what the requirements are, or what the
problem being addressed is.
This rejection forms part of an on-going communication and it is
expected that the process will continue with further iterations.
- Out of scope for the IETF. Many stages of this process may
determine that the requirements are out of scope for the IETF. In this case, the IETF MUST NOT constrain the authors of the
requirements statement I-D from working on a solution. If any
(G)MPLS changes are later identified, the requestor MUST reinitiate the (G)MPLS change procedure.
- No protocols extensions or changes are needed. At some stage in
the evaluation of the requirements it may become clear that they
can all be met through appropriate use of existing protocols. In Andersson & Farrel Best Current Practice [Page 16]
this case, no further evaluation of the requirements is required,
but the REWG MUST explain how the protocols can be used to meet the requirements and MAY cooperate with the authors of the requirements statement I-D in the production of an Applicability Statement
Internet-Draft or a Profiles Internet-Draft that explains precisely how the existing protocols can be used to meet the requirements.
- Insufficient support within the IETF. Although the work described within the requirements statement I-D is within scope for the IETF, and despite the support of the originators of the requirements
statement I-D on the REWG mailing list, the chairs of the REWG have determined that there is insufficient support in the REWG to
complete requirements statement I-D and initiate solutions work in the PSWG. In this case, the IETF MUST NOT restrict the authors of the requirements statement I-D from working on a solution. The
solution (and/or IANA codepoints requested) SHALL be presented to
the IETF’s (G)MPLS PSWG for review and possible publication as an
Informational or Experimental RFC, and, pending IETF review
results, the IETF SHALL NOT block applications to IANA for
codepoints. If IANA codepoint assignments are required, the IANA
Requirements prescribed for those assignments in the relevant RFCs MUST be satisfied. It is highly recommended for the SDO to
encourage its participants to participate in the IETF work to
ensure appropriate industry representation in the work.
- Insufficient support for the work from the original requesters. If the authors of the requirements statement I-D do not make
themselves available on the REWG mailing list for discussion of the requirements or do not contribute the completion of the
requirements statement I-D, the chairs of the REWG MAY determine
that there is insufficient support for the work and MAY reject the requirements statement I-D. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other
organization, and MUST NOT endorse the publication of any changes
or extensions to the (G)MPLS protocols and MUST NOT instruct IANA
to allocate any codepoints. The requirements may be reintroduced
by starting the procedure again from the top.
- Satisfying the requirements would break the technology. It is
possible that an assessment will be made that, although the
requirements are reasonable, it is not possible to satisfy them
through extensions or changes to the (G)MPLS protocols without
violating the (G)MPLS architecture in such a way as would break the (G)MPLS technology. In this case, a recommendation will be made
that some other technology be used to satisfy the requirements.
See Section 7 for further discussions of the protection of the
integrity of the (G)MPLS technology. In this case, the IETF MUST
NOT grant permission for the work to be carried out in any other Andersson & Farrel Best Current Practice [Page 17]
organization, and MUST NOT endorse the publication of any changes
or extensions to the (G)MPLS protocols and MUST NOT instruct IANA
to allocate any codepoints.
5.2. Actions Required When Rejecting Requirements Statement I-Ds
Upon rejection, the IETF MUST make a clear statement of why the
requirements statement I-D has been rejected and what next step
actions are acceptable (refer to Section 5.1).
The communication of the rejection depends on the form of the
original submission as follows.
- If the requirements are brought to the IETF as a preliminary
investigation (see Section 4.2.1) through an email exchange then
the response MUST be made as an email response copied to an IETF
mailing list so that it is automatically archived.
- If the requirements are brought to the IETF as a preliminary
investigation (see Section 4.2.1) through a formal liaison, the
rejection MUST be delivered through a formal liaison response.
- If a requirements statement I-D has been produced and discussed on an IETF email list, the response MUST be made as an email response and copied to the email list.
- If a requirements statement I-D has been produced and brought to
the IETF through a formal liaison, the rejection MUST be delivered through a formal liaison response.
- If an IETF working group has been involved in the review or
production of any Internet-Drafts for the requirements or for the
solutions, the working group MUST be notified of the rejection and the reasons.
The responsibility for the generation of the response lies with the
person, people, or group that instigates the rejection. This may be the IESG, one or more Area Directors, one or more working group
chairs, or a designated expert [RFC2434]. In the case of the use of a liaison relationship, the IETF’s liaison manager has responsibility for ensuring that the procedures in this document, and particularly
the rejection procedures, are followed.
5.3. Appeals
[RFC2026] contains additional information related to procedure
disagreements and appeals. The rejection of a requirements statement I-D as described in Sections 5.1 and 5.2 may be appealed in the event Andersson & Farrel Best Current Practice [Page 18]
it is disputed and cannot be reversed by direct discussion between
the parties. The conflict resolution and appeal mechanism is
documented in [RFC2026].
6. Abandonment of the Solutions I-D
Once the solutions work has been started by the PSWG, it may be
abandoned before completion. This can happen if the PSWG chairs
determine that there is no longer working group support for doing the work. This could arise, for example, if no one (including the
originators of the requirements statement I-D) is willing to
contribute to the development of a solutions I-D.
In the event that the solutions work is abandoned by the PSWG, the
Area Directors responsible for the PSWG MUST be consulted. The
originators of the requirements statement I-D MUST be informed that
the work has been abandoned using a mechanism dependent on how the
requirements were introduced (as discussed in Section 5.2).
If the solution is abandoned in this way, work on solutions for the
requirements MUST NOT be started in another forum. The status of
extensions and changes to the (G)MPLS protocols with regard to the
specific requirements returns to how it was before the process
started. Any new examination of the requirements MUST commence at
the top of the process.
6.1. Appeals
The abandonment of a solutions I-D may be appealed in the event it is disputed and cannot be reversed by direct discussion between the
parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
7. (G)MPLS Integrity and Ownership
The (G)MPLS working groups are REQUIRED to protect the architectural integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS
architecture with features that do not have general use beyond the
specific case. They also MUST NOT modify the architecture just to
make some function more efficient at the expense of simplicity or
generality.
The architectural implications of additions or changes to the (G)MPLS protocols MUST consider interoperability with existing and future
versions of the protocols. The effects of adding features that
overlap, or that deal with a point solution and are not general, are much harder to control with rules and risk impacting the protocol as a whole. Therefore, to minimize operational and technical risks to Andersson & Farrel Best Current Practice [Page 19]
the (G)MPLS technology, IETF processes SHALL be followed for any
requests on extensions to (G)MPLS protocols. With respect to (G)MPLS protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS
protocol, as long as the working group exists. All changes or
extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG.
8. Security Considerations
All requirements statement I-Ds MUST give full consideration to the
security impact of the proposed additional features or functions.
All solutions I-Ds MUST consider the impact on the security of the
protocol extensions and to the pre-existing protocol.
This documents does not itself introduce any security issues for any (G)MPLS protocols.
The IETF process is itself at risk from denial of service attacks.
This document utilizes the IETF process and adds clarity to that
process. It is possible, therefore, that this document might put the IETF process at risk.
Therefore, provided that the number of requirements statement I-Ds is not unreasonable, there will be no significant impact on the IETF
process. The rate of arrival of requirements statement I-Ds MAY be
used by the IESG to detect denial of service attacks, and the IESG
SHOULD act on such an event depending on the source of the
requirements statement I-D and the perceived relevance of the work.
The IESG might, for example, discuss the issue with the management of external organizations.
9. Acknowledgements
The input given by Bert Wijnen has been useful and detailed.
Review feedback and discussions with various members of the ITU-T has been helpful in refining the process described in this document.
Thanks in particular to the members of Question 14 of Study Group 15, and to the management of Study Group 15. Important discussions were held with the following participants in the ITU-T: Yoichi Maeda, Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, George Newsome,
Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, and Ben Mack-
Crane.
Thanks for further review comments to Brian Carpenter, Stewart
Bryant, Sam Hartman, Mark Townsley, and Dave Ward. Thanks to Spencer Dawkins for the GenArt review.
Andersson & Farrel Best Current Practice [Page 20]
助焊剂技术标准 免清洗液态助焊剂——————————————————————————————————————— 1 范围 本标准规定了电子焊接用免清洗液态助焊剂的技术要求、实验方法、检验规则和产品的标志、包装、运输、贮存。 本标准主要适用于印制板组装及电气和电子电路接点锡焊用免清洗液态助焊剂（简称助焊剂）。使用免清洗液态助焊剂时，对具有预涂保护层印制板组件的焊接，建议选用与其配套的预涂覆助焊剂。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否使用这些文件。凡是不注日期的引用文件，其最新版本适用于本标准。GB 190 危险货物包装标志 GB 2040 纯铜板 GB 3131 锡铅焊料 GB 电工电子产品基本环境试验规程润湿称量法可焊性试验方法 GB 2828 逐批检查计数抽样程序及抽样表（适用于连续批的检查） GB 2829 周期检查计数抽样程序及抽样表（适用于生产过程稳定性的检查） GB 4472 化工产品密度、相对密度测定通则 GB 印制板表面离子污染测试方法 GB 9724 化学试剂PH值测定通则 YB 724 纯铜线 3 要求 外观 助焊剂应是透明、均匀一致的液体，无沉淀或分层，无异物，无强烈的刺激性气味； 在——————————————————————————————————————— 中华人民共和国信息产业部标 200X-XX-XX发布200X-XX-XX实施 SJ/T 11273-2002 ——————————————————————————————————————— 一年有效保存期内，其颜色不应发生变化。 物理稳定性 按试验后，助焊剂应保持透明，无分层或沉淀现象。 密度 按检验后，在23℃时助焊剂的密度应在其标称密度的（100±）%范围内。
JESMAY 培训资料 焊接质量检验标准焊接在电子产品装配过程中是一项很重要的技术，也是制造电子产品的重要环节之一。它在电子产品实验、调试、生产中应用非常广泛，而且工作量相当大，焊接质量的好坏，将直接影响到产品的质量。电子产品的故障除元器件的原因外，大多数是由于焊接质量不佳而造成的。因此，掌握熟练的焊接操作技能对产品质量是非常有必要的。（一）焊点的质量要求：保证焊点质量最关键的一点，就是必应该包括电气接触良好、机械接触牢固和外表美观三个方面，对焊点的质量要求，须避免虚焊。1．可靠的电气连接锡焊连接不是靠压力而是靠焊接过程形成牢固连接的合金层达到电焊接是电子线路从物理上实现电气连接的主要手段。气连接的目的。如果焊锡仅仅是堆在焊件的表面或只有少部分形成合金层，也许在最初的测试和工作中不易发现焊点存在的问题，这种焊点在短期内也能通过电流，但随着条件的改变和时间的推移，接触层氧化，脱离出现了，电路产生时通时断或者干脆不工作，而这时观察焊点外表，依然连接良好，这是电子仪器使用中最头疼的问题，也是产品制造中必须十分重视的问题。2．足够机械强度为保证被焊件在受振动或冲击时不至脱落、同时也是固定元器件，保证机械连接的手段。焊接不仅起到电气连接的作用，松动，因此，要求焊点有足够的机械强度。一般可采用把被焊元器件的引线端子打弯后再焊接的方法。作为焊锡材料的铅锡2。要想增加强度，就要有足够的，只有普通钢材的合金，本身强度是比较低的，常用铅锡焊料抗拉强度约为3-4.7kg/cm10% 连接面积。如果是虚焊点，焊料仅仅堆在焊盘上，那就更谈不上强度了。3．光洁整齐的外观并且不伤及导线的绝缘层及相邻元件良好桥接等现象，良好的焊点要求焊料用量恰到好处，外表有金属光泽，无拉尖、的外表是焊接质量的反映，注意：表面有金属光泽是焊接温度合适、生成合金层的标志，这不仅仅是外表美观的要求。 主焊体所示，其共同特点是：典型焊点的外观如图1①外形以焊接导线为中心，匀称成裙形拉开。 焊接薄的边缘凹形曲线焊料的连接呈半弓形凹面，焊料与焊件交界处平② 滑，接触角尽可能小。③表面有光泽且平滑。1图④无裂纹、针孔、夹渣。焊点的外观检查除用目测（或借助放大镜、显微镜观测）焊点是否合乎上述标准以外，还包括以下几个方面焊接质量的；导线及元器件绝缘的损伤；布线整形；焊料飞溅。检查时，除检查：漏焊；焊料拉尖；焊料引起导线间短路（即“桥接”）目测外，还要用指触、镊子点拨动、拉线等办法检查有无导线断线、焊盘剥离等缺陷。（二）焊接质量的检验方法：⑴目视检查目视检查就是从外观上检查焊接质量是否合格，也就是从外观上评价焊点有什么缺陷。目视检查的主要内容有： 是否有漏焊，即应该焊接的焊点没有焊上；① ②焊点的光泽好不好； ③焊点的焊料足不足；(a)(b) ④焊点的周围是否有残留的焊剂；正确焊点剖面图2图6-1 JESMAY 培训资料
场效应管是利用电场效应来控制电流的一种半导体器件，它的输出电流决定于输入电压的大小，基本上不需要信号源提供电流，所以输入电阻高，且温度稳定性好。 绝缘栅型场效应管 MOS管增强型NMOS管耗尽型NMOS管增强型PMOS管耗尽型PMOS管 1.4 绝缘栅场效应管(IGFET)
1. G 栅极D 漏极 S 源极B 衬极 SiO 2 P 型硅衬底耗尽层 N + N + 栅极和其它电极之间是绝缘的，故称绝缘栅场效应管。 MOS Metal oxide semiconductor 1.4.1 N 沟道增强型绝缘栅场效应管(NMOS)电路符号 D G S
G D S B P N + N + 2. 工作原理 (1) U GS 对导电沟道的控制作用(U DS =0V) 当U GS ≥U GS(th)时，出现N 型导电沟道。 耗尽层 开启电压：U GS(th) U GS N 型沟道 U GS 值越大沟道电阻越小。
G D S B P N + N + (2) U DS 对导电沟道的影响(U GS >U GS(th)) U GS U DD R D U DS 值小，U GD >U GS(th)，沟道倾斜不明显，沟道电阻近似不变，I D 随U DS 线性增加。 I D U GD =U GS -U DS 当U DS 值增加使得U GD =U GS(th)，沟道出现预夹断。U DS =U GS -U GS(th) 随着U DS 增加，U GD
1 234 U GS V 2 4 6I D /mA 3. 特性曲线 输出特性曲线:I D =f (U DS ) U GS =常数 转移特性曲线:I D =f (U GS ) U DS =常数 U GS =5V 6V 4V 3V 2V U DS =10V 恒流区 U GS(th) U DS /V 5 10 151 234 I D /mA 可变电阻区 截止区 U GD =U GS(th) 2 GS D DO GS(th)1U I I U ?? =- ? ??? I DO 是U GS =2U GS(th)时的I D 值 I DO U GD >U GS(th) U GD 产品质量检验标准
CaiNi accessories factory
第 1 页 共 1 页
采 妮 饰 品 厂
产品品质检验标准
一、目的: 产品及产品用料检验工作，规范检验过程的判定标准和判定等级，使产品出货的品质满足顾 确保本工厂产品和产品用料品质检验工作的有效性。 二、本标准的适用范围: 本标准适用采妮工厂所有生产的产品及产品用料的品质检验。 三、权责: 1、品质部:检验标准及检验样本的制定，产品检验及判定、放行。 2、生产车间、物控部:所有产品及产品用料报检和产品品质异常的处理。 3、总经理:特采出货及特采用料的核准。 四、定义 1、首饰类: A、项链/手链/腰链 F、发夹 G、手表带 B、耳环 H、领夹 C、胸针 D、介子 E、手镯 J、皮带扣
规范工厂
客需求，
I、袖口钮/鞋扣钮
K、其他配件类(服装、皮包、眼镜等等) 2、产品用料: A、铝质料类 F、钛金属 B、铜料类 G、皮革类 C、铅锡合金 H、不锈钢类 D、锌合金 E、铁质料类 J、包装用料类
I、水晶胶类
K、硅料类(玻璃珠、玻璃石、宝石、珍珠、玛瑙) 3、客户品质等级分类及说明: 1）客户品质等级分类: 品质部根据客户订单注明的: “AAA”、“AA”、“A”三个等级分别对客户品质标准进 行分类 。 2）客户品质等级说明: A、 “AAA”: 品质标准要求比较严格，偏高于正常标准和行业标准。 B、 “AA”: 品质标准要求通用国际化标准和行业标准吻合。 C、 “A”: 品质要求为一般市场通用品质标准。
第 1 页 共 1 页
某光源发出波长为460nm 的单色光，辐射功率为100W ，用Y 值表示其光通量，计算其色度坐标X 、Y 、Z 、x 、y 。 解：由教材表1-3查得460nm 单色光的三色视觉值分别为0.2908X =，0.0600Y =， 1.6692Z =，则对100W P =，有 4356831000.2908 1.98610lm 6831000.0600 4.09810lm 683100 1.6692 1.14010lm m m m X K PX Y K PY Z K PZ ==××=×==××=×==××=× 以及 )()0.144 0.030x X X Y Z y Y X Y Z =++==++=
1. GaP绿色LED的发光机理是什么，当氮掺杂浓度增加时，光谱有什么变化，为什么？GaP红色LED的发光机理是什么，发光峰值波长是多少？ 答：GaP绿色LED的发光机理是在GaP间接跃迁型半导体中掺入等电子陷阱杂质N，代替P原子的N原子可以俘获电子，又靠该电子的电荷俘获空穴，形成束缚激子，激子复合发光。当氮掺杂浓度增加时，总光通量增加，主波长向长波移动，这是因为此时有大量的氮对形成新的等电子陷阱，氮对束缚激子发光峰增加，且向长波移动。 GaP红色LED的发光机理是在GaP晶体中掺入ZnO对等电子陷阱，其发光峰值波长为700nm的红光。 2. 液相外延生长的原理是什么？一般分为哪两种方法，这两种方法的区别在哪里？ 答：液相外延生长过程的基础是在液体溶剂中溶质的溶解度随温度降低而减少，而且冷却与单晶相接触的初始饱和溶液时能够引起外延沉积，在衬底上生长一个薄的外延层。 液相外延生长一般分为降温法和温度梯度法两种。降温法的瞬态生长中，溶液与衬底组成的体系在均处于同一温度，并一同降温（在衬底与溶液接触时的时间和温度上，以及接触后是继续降温还是保持温度上，不同的技术有不同的处理）。而温度梯度法则是当体系达到稳定状态后，整个体系的温度再不改变，而是在溶液表面和溶液－衬底界面间建立稳定的温度梯度和浓度梯度。 3. 为何AlGaInP材料不能使用通常的气相外延和液相外延技术来制造？ 答：在尝试用液相外延生长AlGaInP时，由于AlP和InP的热力学稳定性的不同，液相外延的组分控制十分困难。而当使用氢化物或氯化物气相外延时，会形成稳定的AlCl化合物，会在气相外延时阻碍含Al磷化物的成功生长。因此AlGaInP 材料不能使用通常的气相外延和液相外延技术来制造。
. '. 检验规范 INSPECTION INSTRUCTION 第1页 / 共2页 版本 变更内容 日期 编写者 名称 A 新版 可焊性试验规范 设备 EQUIPMENT 熔锡炉,温度计,显微镜 1.0 目的： 阐述可焊性试验的方法及验收标准 2.0 范围： 适用于上海molex 组装产品的针/端子的可焊性试验 3.0 试验设备与材料: 3.1 试验设备 熔锡炉`温度计`显微镜 3.2 试验材料 无水酒精`助焊剂(液体松香)`焊锡(Sn60或Sn63) 4.0 定义： 4.1 沾锡—--焊锡在被测金属表面上形成一层均匀`光滑`完整而附着的锡层状态,具体见图片A. 4.2 缩锡—--上锡时熔化焊锡覆盖了整个被测表面,试样产品离开熔炉后, 在被测表面上形成形状不规则的锡块,基底金属不暴露, 具体见图片B. 4.3不粘锡—试样产品离开熔锡炉后,被测表面仍然暴露,未形成锡层, 具体见图片C. 4.4 针孔----穿透锡层的小孔状缺陷, 具体见图片D 。 图片A (焊接测试合格) 图片B(表面形成不规则的锡块) 编写者: 校对: 批准: 缩锡 表面形成均匀`光滑`完整而附着的锡层状态
. '. 检验规范 INSPECTION INSTRUCTION 第2页 / 共2页 图片C (铜基底未被锡层覆盖) 图片D (表面有小孔缺陷) 5.0 程序: 5.1试样准备 应防止试样产品沾染油迹,不应刻意的对试样进行清洗`擦拭等清洁工作,以免影响试验的客观性. 5.2熔锡 打开熔锡炉,熔化焊锡,并使熔锡温度保持在245?C ±5?C. 5.3除渣 清除熔锡池表面的浮渣或焦化的助焊剂. 5.4上助焊剂 确保试样产品直立浸入助焊剂中5-10sec,再取出使其直立滴流10-20sec,使的被测部位不会存在多余助焊剂.浸入深度须覆盖整个待测部分. 5.5 上锡 确保试样产品直立浸入熔剂池中5±0.5sec ,以25±6mm/sec 的速度取出,浸入深度须覆盖整个待测 部分. 5.6 冷却 上锡完成后,置放自然冷却. 5.7 清洗 将冷却后的试样产品浸入无水酒精中除去助焊剂,清洗完成后,置于无尘纸上吸干溶液. 6.0 验收标准 在30倍的显微镜下观察,针孔`缩锡`不沾锡等缺陷不得集中于一处,且缺陷所占面积不得超过整个测试面积的5%, 不沾锡 针孔
助焊剂的檢驗方法(依據標准) 项目 规格 测试标准 助焊剂分类 ORM0 J-STD-004 物理状态（20℃） 液体 目测 颜色 无色 目测 比重（20℃） 0.822±0.010 GB611-1988 酸价（mgKOH/g） 49.00±5.00 J-STD-004 固态含量（w/w%） 7.50±1.00 JIS-Z-3197 卤化物含量 (w/w%) 无 J-STD-004/2.3.35 吸入容许浓度 (ppm) 400 WS/T206-2001 助焊剂检测方法 6.1助焊剂外观的测定 目视检测成品外观应均匀一致，透明，无沉淀、分层现象，无异物。 6.2助焊剂固体含量的测定 6.2.1(重量分析法) A）原理 将已称重的助焊剂样品先后在水浴及烘箱中除去挥发性物质，冷却后再称重。 助焊剂的固体含量由以上所得到的数值计算而得。 B）仪器 A.实验室常规仪器 B.水浴 C.烘箱 D.电子天平：灵敏度为0.0001g C）步骤 A.有机溶剂助焊剂(沸点低于100℃)： a.将烧杯放入恒温110℃± 5℃的烘箱中烘干，放入干燥器中，冷却至室温， 称重(精确至0.001g)。重复以上操作直至烧杯恒重(两次称量相差不超过 0.001g)。 b.移取足量的样品1.0±0.1入烧杯，称重(精确至0.001g)。 c.将烧杯放入110 ± 2℃烘箱中烘1小时，取出后在干燥器中冷却至室温称重 (精确至0.001g) 。 B.水溶剂助焊剂： a.将烧杯放入恒温110°± 2℃的烘箱中烘干，放入干燥器中，冷却至室温，称 重(精确至0.001g)。重复以上操作直至烧杯恒重(两次称量相差不超过 0.001g)。 b.移取足量的样品1.0±0.1入烧杯，称重(精确至0.001g)。 c.将烧杯放入110 ±2℃烘箱中烘3小时，取出后在干燥器中冷却至室温称重 (精确至0.001g) 。
LED半导体照明的发展与应用 者按：半导体技术在上个世纪下半叶引发的一场微电子革命，催生了微电子工业和高科技ＩＴ产业，改变了整个世界的面貌。今天，化合物半导体技术的迅猛发展和不断突破，正孕育着一场新的革命——照明革命。新一代照明光源半导体ＬＥＤ，以传统光源所没有的优点引发了照明产业技术和应用的革命。半导体ＬＥＤ固态光源替代传统照明光源是大势所趋。１、ＬＥＤ半导体照明的机遇 （１）全球性的能源短缺和环境污染在经济高速发展的中国表现得尤为突出，节能和环保是中国实现社会经济可持续发展所急需解决的问题。作为能源消耗大户的照明领域，必须寻找可以替代传统光源的新一代节能环保的绿色光源。 （２）半导体ＬＥＤ是当今世界上最有可能替代传统光源的新一代光源。 其具有如下优点： ①高效低耗，节能环保； ②低压驱动，响应速度快安全性高； ③固体化封装，耐振动，体积小，便于装配组合； ④可见光区内颜色全系列化，色温、色纯、显色性、光指向性良好，便于照明应用组合； ⑤直流驱动，无频闪，用于照明有利于保护人眼视力； ⑥使用寿命长。 （３）现阶段ＬＥＤ的发光效率偏低和光通量成本偏高是制约其大规模进入照明领域的两大瓶颈。目前ＬＥＤ的应用领域主要集中在信号指示、智能显示、汽车灯具、景观照明和特殊照明领域等。但是，化合物半导体技术的迅猛发展和关键技术的即将突破，使今天成为大力发展半导体照明产业的最佳时机。２００３年我国人均ＧＤＰ首次突破１０００美元大关，经济实力得到了进一步的增强，市场上已经初步具备了接受较高光通量成本（初始成本）光
源的能力。在未来的１０～２０年内，用半导体ＬＥＤ作为光源的固态照明灯，将逐渐取代传统的照明灯。 （４）各国政府予以高度重视，相继推出半导体照明计划，已形成世界性的半导体照明技术合围突破的态势。 ①美国：“下一代照明计划”时间是２０００～２０１０年投资５亿美元。美国半导体照明发展蓝图如表１所示； ②日本：“２１世纪的照明计划”，将耗费６０亿日元推行半导体照明目标是在２００６年用白光ＬＥＤ替代５０％的传统照明； ③欧盟：“彩虹计划”已在２０００年７月启动通过欧共体的资助推广应用白光ＬＥＤ照明； ④中国：２００３年６月１７日，由科技部牵头成立了跨部门、跨地区、跨行业的“国家半导体照明工程协调领导小组”。从协调领导小组成立之日到２００５年年底之前，将是半导体照明工程项目的紧急启动期。从２００６年的“十一五”开始，国家将把半导体照明工程作为一个重大项目进行推动； （５）我国 的半导体ＬＥＤ产业链经过多年的发展已相对完善，具备了一定的发展基础。同时，我国又是照明灯具产业的大国，只要政府和业界协调整合好，发展半导体ＬＥＤ照明产业是大有可为的； ２ＬＥＤ的发展历程（如图１所示） ２．１ＬＥＤ技术突破的历程
助焊剂通用规范 2014-08-15发布2014-09-01实施 xxx电子分厂发布
助焊剂通用规范 免清洗液态助焊剂——————————————————————————————————————— 1 范围 本标准规定了电子焊接用免清洗液态助焊剂的技术要求、实验方法、检验规则和产品的标志、包装、运输、贮存。 本标准主要适用于印制板组装及电气和电子电路接点锡焊用免清洗液态助焊剂（简称助焊剂）。使用免清洗液态助焊剂时，对具有预涂保护层印制板组件的焊接，建议选用与其配套的预涂覆助焊剂。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否使用这些文件。凡是不注日期的引用文件，其最新版本适用于本标准。 GB 190 危险货物包装标志 GB 2040 纯铜板 GB 3131 锡铅焊料 GB 2423.32 电工电子产品基本环境试验规程润湿称量法可焊性试验方法 GB 2828 逐批检查计数抽样程序及抽样表（适用于连续批的检查） GB 2829 周期检查计数抽样程序及抽样表（适用于生产过程稳定性的检查） GB 4472 化工产品密度、相对密度测定通则 GB 4677.22 印制板表面离子污染测试方法 GB 9724 化学试剂PH值测定通则 YB 724 纯铜线 3 要求 3.1 外观 助焊剂应是透明、均匀一致的液体，无沉淀或分层，无异物，无强烈的刺激性气味；一年有效保存期内，其颜色不应发生变化。 3.2 物理稳定性 按5.2试验后，助焊剂应保持透明，无分层或沉淀现象。 3.3 密度 按5.3检验后，在23℃时助焊剂的密度应在其标称密度的（100±1.5）%范围内。 3.4 不挥发物含量 按5.4检验后，助焊剂不挥发物含量应满足表1的规定。
《半导体照明技术及其应用》课程教学大纲 （秋季） 一、课程名称：半导体照明技术及其应用Semiconductor Lighting Technology and Applications 二、课程编码： 三、学时与学分：32/2 四、先修课程: 微积分、大学物理、固体物理、半导体物理、微电子器件与IC设计 五、课程教学目标： 半导体照明是指用全固态发光器件LED作为光源的照明，具有高效、节能、环保、寿命长、易维护等显著特点，是近年来全球最具发展前景的高新技术领域之一，是人类照明史上继白炽灯、荧光灯之后的又一场照明光源的革命。本课程注重理论的系统性﹑结构的科学性和内容的实用性，在重点讲解发光二极管的材料、机理及其制造技术后，详细介绍器件的光电参数测试方法，器件的可靠性分析、驱动和控制方法，以及各种半导体照明的应用技术，使学生学完本课程以后，能对半导体照明有深入而全面的理解。 六﹑适用学科专业：电子科学与技术 七、基本教学内容与学时安排： 绪论（1学时） 半导体照明简介、学习本课程的目的及要求 第一章光视觉颜色（2学时） 1光的本质 2光的产生和传播 3人眼的光谱灵敏度 4光度学及其测量 5作为光学系统的人眼 6视觉的特征与功能 7颜色的性质 8国际照明委员会色度学系统 9色度学及其测量 第二章光源（1学时） 1太阳 2月亮和行星 3人工光源的发明与发展 4白炽灯 5卤钨灯 6荧光灯 7低压钠灯
8高压放电灯 9无电极放电灯 10发光二极管 11照明的经济核算 第三章半导体发光材料晶体导论（2学时） 1晶体结构 2能带结构 3半导体晶体材料的电学性质 4半导体发光材料的条件 第四章半导体的激发与发光（1学时） 1PN结及其特性 2注入载流子的复合 3辐射与非辐射复合之间的竞争 4异质结构和量子阱 第五章半导体发光材料体系（2学时） 1砷化镓 2磷化镓 3磷砷化镓 4镓铝砷 5铝镓铟磷 6铟镓氮 第六章半导体照明光源的发展和特征参量（1学时）1发光二极管的发展 2发光二极管材料生长方法 3高亮度发光二极管芯片结构 4照明用LED的特征参数和要求 第七章磷砷化镓、磷化镓、镓铝砷材料生长（3学时）1磷砷化镓氢化物气相外延生长（HVPE） 2氢化物外延体系的热力学分析 3液相外延原理 4磷化镓的液相外延 5镓铝砷的液相外延 第八章铝镓铟磷发光二极管（2学时） 1AlGaInP金属有机物化学气相沉积通论 2外延材料的规模生产问题 3电流扩展 4电流阻挡结构 5光的取出 6芯片制造技术
PCB.A焊锡作业标准及通用检 验标准 【培训教材】 部门: 工艺工程部 编制: 代建平 ※烙铁工作原理 ※烙铁的分类及适用范围 ※烙铁使用前的准备 ※烙铁的使用与操作 ※一般无铅组件焊接参考温度及时间 ※烙铁的使用注意事项及保养要求 ※焊点的焊接标准及焊点的判别 ※焊点不良的原因分析 ※焊接的操作顺序 审查﹕核准﹕版本﹕
A B D E F A. 滑动盖 D 未端 B. 滑动柱 E 感应器 C. 未端 F 测量点 C 1. 目的：为使作业者正确使用电烙铁进行手工焊接作业，使电烙铁得到有效的利用，特制定本教材。 2. 范围：升邦钟表制品厂所有使用电烙铁，烙铁架的人员。 3. 定义： 恒温烙铁：是一种能在一定温度范围自由调节烙铁发热温度，并稳定在较小温度范围内的手工焊接工具，一般在100℃-400℃可调，温度稳定性达±5℃或更好状况。 4.工作原理：通过能量转换使锡合金熔化后适量转移到工件预焊位置,使其凝固,达到人们预期的目的。 5.内容： 5.1电烙铁的分类及适用范围： 5.1.1：一般情况下，烙铁按功率分，可分为30W 烙铁、40W 烙铁、60W 烙铁、恒温烙铁等几种类型，按加热方式分可分 为内热式、外热式。30W 烙铁温度能控制在250℃-300℃之间；40W 烙铁温度能控制在280℃-360℃之间； 60W 烙铁温度能控制在350℃-480℃之间；恒温烙铁具有良好的温度稳定性能，因其温度能在100℃-400℃之间可调和稳定，因此可适用各种焊接环境，因内热式具有发热稳定，不易损坏等优点，所以目前大多数使用内热式烙铁。 5.1.2：烙铁嘴一般是采用紫铜或类似合金的材料制成, 其特点是传热快, 易与锡合金物亲合，烙铁头根据焊接物的大小 形状要求不同的形状, 通常有圆锥、斜圆、扁平、一字形…，通常电烙铁配置相同功率的烙铁嘴，因圆锥型烙铁嘴适用各种焊接环境，尤其在组件脚较密，普通电子组件、焊盘焊接位置较紧凑的位置，焊接对温度敏感组件或其它易烫坏组件和焊盘的环境下使用，具有其不可替代的优越性，如封装IC 脚焊接，普通电容、电阻、二极管排线、石英的焊接等，所以在工厂里运用较多。 5.2：电烙铁的使用前准备： 5.2.1：恒温烙铁是通过电源插线把电源与焊台连接起来的, 一般使用总插头+防静电线, 其中总插头为电源线, 另一根线 为防静电连接线, 在焊接有特殊要求的器件时, 必须作好防静电保护，（烙铁的接地线必须接地）因此电烙铁使用前应由生产管理人员检查烙铁电源线及地线是否有铜线外露或胶落，电源插头接线有无脱落，烙铁嘴是否有松动、破损等，如有异常情况，应及时交由工艺工程部相关人员维修或更换。 5.2.2：使用电烙铁，须配套领取烙铁架，同时应将海棉浸湿再挤干后置入烙铁架相应位置，以作烙铁嘴擦拭之用。 5.2.3：将恒温烙铁插上电源，2分钟左右，烙铁嘴将迅速升温至所设定温度，这时应将烙铁嘴在湿润的海棉上擦拭干净 用锡线在烙铁嘴上涂上薄薄的一层锡，再次在海棉上擦拭到烙铁嘴光亮后方可使用。 5.2.4：电烙铁在开始使用或在使用过程中，须由IPQC 对烙铁嘴的温度及感应电压进行监测，一般监测温度使用烙铁温 度测试仪，监测感应电压使用数字万用表，以确保其焊接温度及感应电压在工艺要求范围，一般至少每4小时须检查一次. 监测烙铁温度具体检测步骤如下： （1）打开电池箱检查电池并确认电池安装极性正确； （2）装传感器红色的一边装到红色的未端C ，装传感器蓝色的一边到蓝色的未端D ；推动滑动盖A 并装另一边到 滑动柱B ； （3）打开电源开关，检查显示屏是否有显示，显示出当时室温时，可以使用该仪器，将使用中的烙铁嘴加上薄 薄一层锡后密切接触到测试点F 上，显示器上将在2-3S 钟内显示烙铁温度。
焊点工艺标准及检验规范文件编号 页数生效日期 冷焊 OK NG 特点：焊点程不平滑之外表，严重时于线脚四周，产生这褶裰或裂缝 1.焊锡表面粗糙，无光泽，程粒状。 2.焊锡表面暗晦无光泽或成粗糙粒状，引脚与铜箔未完全熔接。 允收标准：无此现象即为允收，若发现即需二次补焊。 影响性：焊点寿命较短，容易于使用一段时间后，开始产生焊接不良之现象，导致功能失效。 造成原因：1.焊点凝固时，收到不当震动（如输送皮带震动） 2.焊接物（线脚、焊盘）氧化。 3.润焊时间不足。 补救处置：1.排除焊接时之震动来源。 2.检查线脚及焊盘之氧化状况，如氧化过于严重，可事先去除氧化。 3.调整焊接速度，加长润焊时间。 编制审核批准 日期日期日期
焊点工艺标准及检验规范文件编号 页数生效日期 针孔 OK NG 特点：于焊点外表上产生如针孔般大小之孔洞。 允收标准：无此现象即为允收，若发现即需二次补焊。 影响性：外观不良且焊点强度较差。 造成原因：1.PCB含水汽。 2.零件线脚受污染（如矽油） 3.导通孔之空气受零件阻塞，不易逸出。 补救处置：1.PCB过炉前以80~100℃烘烤2~3小时。 2.严格要求PCB在任何时间任何人都不得以手触碰PCB表面，以避免污染。 3.变更零件脚成型方式，避免Coating（零件涂层）落于孔内，或察看孔径与线搭配是否有风孔之现象。 编制审核批准 日期日期日期
焊点工艺标准及检验规范文件编号 页数生效日期 短路 OK NG 特点：在不同线路上两个或两个以上之相邻焊点间，其焊盘上这焊锡产生相连现象。 1.两引脚焊锡距离太近小于0.6mm，接近短路。 2.两块较近线路间被焊锡或组件弯角所架接，造成短路。 允收标准：无此现象即为允收，若发现即需二次补焊。 影响性：严重影响电气特性，并造成零件严重损害。 造成原因：1.板面预热温度不足。 2.助焊剂活化不足。 3.板面吃锡高度过高。 4.锡波表面氧化物过多。 5.零件间距过近。 6.板面过炉方向和锡波方向不配合。 补救处置：1.调高预热温度。 2.更新助焊剂。 3.确认锡波高度为1/2板厚高。 4.清除锡槽表面氧化物。 5.变更设计加大零件间距。 6.确认过炉方向，以避免并列线脚同时过炉，或变更设计并列线脚同一方向过炉。 编制审核批准 日期日期日期
第一章 常用半导体器件 自 测 题 一、判断下列说法是否正确，用“√”和“×”表示判断结果填入空内。 （1）在N 型半导体中如果掺入足够量的三价元素，可将其改型为P 型半导体。（ ） （2）因为N 型半导体的多子是自由电子，所以它带负电。（ ） （3）PN 结在无光照、无外加电压时，结电流为零。（ ） （4）处于放大状态的晶体管，集电极电流是多子漂移运动形成的。 （ ） （5）结型场效应管外加的栅-源电压应使栅-源间的耗尽层承受反向电压，才能保证其R G S 大的特点。（ ） （6）若耗尽型N 沟道MOS 管的U G S 大于零，则其输入电阻会明显变小。（ ） 解：（1）√ （2）× （3）√ （4）× （5）√ （6）× 二、选择正确答案填入空内。 （1）PN 结加正向电压时，空间电荷区将 。 A. 变窄 B. 基本不变 C. 变宽 （2）设二极管的端电压为U ，则二极管的电流方程是 。 A. I S e U B. T U U I e S C. )1e (S －T U U I （3）稳压管的稳压区是其工作在 。 A. 正向导通 B.反向截止 C.反向击穿 （4）当晶体管工作在放大区时，发射结电压和集电结电压应为 。 A. 前者反偏、后者也反偏 B. 前者正偏、后者反偏 C. 前者正偏、后者也正偏 （5）U G S ＝0V 时，能够工作在恒流区的场效应管有 。 A. 结型管 B. 增强型MOS 管 C. 耗尽型MOS 管 解：（1）A （2）C （3）C （4）B （5）A C
三、写出图T1.3所示各电路的输出电压值，设二极管导通电压U D＝0.7V。 图T1.3 解：U O1≈1.3V，U O2＝0，U O3≈－1.3V，U O4≈2V，U O5≈1.3V， U O6≈－2V。 四、已知稳压管的稳压值U Z＝6V，稳定电流的最小值I Z mi n＝5mA。求图T1.4所示电路中U O1和U O2各为多少伏。 图T1.4 解：U O1＝6V，U O2＝5V。
助焊剂通用规范 Document number：NOCG-YUNOO-BUYTT-UU986-1986UT
x x x x企业标准 xxx电子分厂发布
助焊剂通用规范 免清洗液态助焊剂——————————————————————————————————————— 1范围 本标准规定了电子焊接用免清洗液态助焊剂的技术要求、实验方法、检验规则和产品的标志、包装、运输、贮存。 本标准主要适用于印制板组装及电气和电子电路接点锡焊用免清洗液态助焊剂（简称助焊剂）。使用免清洗液态助焊剂时，对具有预涂保护层印制板组件的焊接，建议选用与其配套的预涂覆助焊剂。 2规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否使用这些文件。凡是不注日期的引用文件，其最新版本适用于本标准。 GB190危险货物包装标志 GB2040纯铜板 GB3131锡铅焊料 电工电子产品基本环境试验规程润湿称量法可焊性试验方法 GB2828逐批检查计数抽样程序及抽样表（适用于连续批的检查） GB2829周期检查计数抽样程序及抽样表（适用于生产过程稳定性的检查） GB4472化工产品密度、相对密度测定通则 印制板表面离子污染测试方法 GB9724化学试剂PH值测定通则 YB724纯铜线 3要求 外观 助焊剂应是透明、均匀一致的液体，无沉淀或分层，无异物，无强烈的刺激性气味；一年有效保存期内，其颜色不应发生变化。 物理稳定性 按试验后，助焊剂应保持透明，无分层或沉淀现象。 密度 按检验后，在23℃时助焊剂的密度应在其标称密度的（100±）%范围内。 不挥发物含量 按检验后，助焊剂不挥发物含量应满足表1的规定。
电子技术复习 CH14半导体器件 1.本征半导体、N型半导体、P半导体的基本概念；PN的单 向导电特性；温度和参杂浓度对多子和少子的影响。 2.二极管的基本参数（死区电压、导通电压）及相关应用， 学会判断二极管在电路中的工作状态（导通、截止）。掌握含二极管电路的分析方法。 3.了解稳压管的工作原理，基本稳压管稳压电路的分析。(两 稳压管串联、并联) 4.半导体三极管工作状态的特点（放大、饱和、截止）。 5.半导体三极管的管脚的判定 CH15基本放大电路 1.放大电路（共射）的分析方法（直流通路法、微变等效电 路法） 2.静态工作点稳定电路(分压式偏置电路)的结构、特点和分 析方法(静态、动态) 3.射极输出器的特点，电路分析。 4.差分放大电路的输入信号（共模、差模、比较），共模抑制 比的概念（理想共模抑制比=？） CH16集成运算放大器 1.运放的理想化条件 2.运放在线性区和非线性区的分析方法
3. 运放线性应用电路的分析（比例运算[同相（电压跟随器）、反相(反相器)]、反相加法运算、减法运算） CH17电子电路中的反馈 1. 反馈的基本概念 2. 负反馈类型的判断方法（会判断正、负反馈；电压、电流反馈；串联、并联反馈） 3. 负反馈对放大器性能的影响（影响类别？闭环放大倍数？ AF A A f += 1） 4. 自激振荡起振的条件、振荡建立条件、稳振条件？ 5. 典型RC 两种类型电路的电路分析。 CH18直流稳压电源 1. 直流稳压电源的组成及各部分的作用 u 1- + 2. 单相半波、全波(桥式整流)电路的构成和工作原理，二极管的选择依据（计算，见例题和作业题），桥式的输出波形受二极管的影响
1. GaP绿色LED的发光机理是什么，当氮掺杂浓度增加时，光谱有什么变化，为什么？GaP红色LED的发光机理是什么，发光峰值波长是多少？答：GaP绿色LED的发光机理是在GaP间接跃迁型半导体中掺入等电子陷阱杂质N，代替P原子的N原子可以俘获电子，又靠该电子的电荷俘获空穴，形成束缚激子，激子复合发光。当氮掺杂浓度增加时，总光通量增加，主波长向长波移动，这是因为此时有大量的氮对形成新的等电子陷阱，氮对束缚激子发光峰增加，且向长波移动。 GaP红色LED的发光机理是在GaP晶体中掺入ZnO对等电子陷阱，其发光峰值波长为700nm的红光。 2. 液相外延生长的原理是什么？一般分为哪两种方法，这两种方法 的区别在哪里？ 答：液相外延生长过程的基础是在液体溶剂中溶质的溶解度随温度 降低而减少，而且冷却与单晶相接触的初始饱和溶液时能够引起外 延沉积，在衬底上生长一个薄的外延层。 液相外延生长一般分为降温法和温度梯度法两种。降温法的瞬态生 长中，溶液与衬底组成的体系在均处于同一温度，并一同降温（在 衬底与溶液接触时的时间和温度上，以及接触后是继续降温还是保 持温度上，不同的技术有不同的处理）。而温度梯度法则是当体系 达到稳定状态后，整个体系的温度再不改变，而是在溶液表面和溶 液－衬底界面间建立稳定的温度梯度和浓度梯度。 3. 为何AlGaInP材料不能使用通常的气相外延和液相外延技术来制造？答：在尝试用液相外延生长AlGaInP时，由于AlP和InP的热力学稳定性的不同，液相外延的组分控制很困难。而当使用氢化物或氯化物气相外延时，会形成稳定的AlCl化合物，会在气相外延时阻碍含Al磷化物的成功生长。故AlGaInP材料不能用通常的气相外延和液相外延技术来制造。 4. 对三基色体系的白光LED，列出基色光源的三个最佳峰值波长。对荧光转换的白光LED和多芯片的白光LED，这三基色用什么方法来实现？答：三基色体系的白光LED，基色光源的三个最佳峰值波长分别为450nm、540nm和610nm。对荧光转换的白光LED，是用部分被吸收的AlInGaN 芯片的蓝光和适当的绿光和橙红光两种荧光粉来实现。对多芯片白光LED，是用峰值波长600nm附近的AlGaInP基LED，以及峰值波长450nm 和540nm的AlInGaN LED组成。 5. 简要说明LED封装技术发展三个阶段的时间范围、典型LED及其驱动电流、器件应用领域。 答：LED封装技术发展的3个阶段分别为： （1）1962~1989年期间，典型的LED为?3和?5的LED，驱动电流一般小于等于20mA，主要用做信号指示和显示。 （2）1990~1999年，发展了大光通量LED食人鱼和Snap，驱动电流在50~150mA，主要用于大型信号指示，如汽车信号灯、景观照明。 （3）2000年至今，研发和生产了功率型LED，电流≥350mA，开始用于照明，并开始了更大光通量输出的组件的研制和生产。 6. 画出透明衬底的AlGaInP LED的结构示意图，简要说明其芯片制造流程。 答：结构示意图如下图所示。 此LED结构用的是MOCVD生长在GaAs上的双异质结(AlxGa1-x)0.5In0.5P，并在结构上方VPE生长一个小于50μm厚的GaP 窗层。在外延生长后，用通常的化学腐蚀技术移除GaAs吸收衬底，使双异质结结构的N型层暴露，再通过升高温度和加压，将晶片黏结到200~250μm厚的N型GaP衬底上。1. 画出典型的具有GaP窗层和吸收衬底的双异质结AlGaInP LED的结构示意图，简述为什么需要使用电流扩展窗层。 答：结构示意图如下图所示。 为了使LED芯片获得高效的发光，电流扩展是主要关键之一，如 上图的结构，器件的上方覆盖了圆形的金属顶，电流从芯片的顶部 接触通过P型层流下到达结区，在结区发光。但是假如P型层的电 阻太高，电流将扩展很少，而仅仅限在金属之下，光仅仅发生在电极 之下，而且被芯片内部吸收。有效的最好性能的AlGaInP LED是在 通常的双异质结顶部再生长一个厚的P型窗层，而不用AlGaInP材 料。这个电流扩展窗层与AlGaInP相比，具有高的薄层电导率，而 且对发射光是透明的，可以达到很好的电流扩展效果。 4.LED作为城市景观照明中的首选光源的优点：①色彩丰富纯度高、节能②响应时间短，瞬时达到全光输出，可深度调光③体积小、方向 性强④直流低压驱动，简化系统设计，降低电路成本⑤寿命长，工作 安全可靠，维护费用大大降低。景观常用LED灯具有护栏灯、树灯 5. LED的电学性能特点：LED是单向导电器件。LED是个具有PN结结构的半导体器件，具有势垒电势，所以就有导通阈值电压。LED的电流—电压特性是非线性的。LED的正向压降与PN结结温的温度系数为负。流过LED的电流和LED的光通量的比值也是非线性的。 6. 电源驱动方案：（1）低电压驱动。是指用低于LED正向导通压降的电压驱动LED，如一节普通干电池、镍镉电池供电的低功耗照明器件，LED 手电、头灯、应急灯、路障灯、节能台灯等，采用电荷泵式升压变换器（2）过渡电压驱动。是指给LED供电的电源电压值在LED正向压降附近变动。如一节锂电池或两节串联的铅酸蓄电池，电池充满时在4V以上，快用完时在3V以下，应用有矿灯等，是反极性电荷泵式变换器（3）高压驱动。是指给LED供电的电压值高于LED的正向压降，如6V.12V.24V蓄电池，应用有太阳能草坪灯、太阳能庭院灯等，变换器电路是串联开关降压电路。（4）市电驱动。是对半导体照明应用最具有价值的供电方式，中小功率LED采用隔离式单端反激变换器，大功率用桥式变换电路。 7.可靠性试验指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。产品在设计、应用过程中，不断经受自身及外界气候环境及机械环境的影响，而仍需要能够正常工作，这就需要以试验设备对其进行验证，按试验目的可分为筛选试验、例行试验、鉴定验收试验；按照试验项目可分为环境试验和寿命试验。 8. （1）平均寿命：指一批电子器件产品寿命的平均值（2）可靠寿命：指一批电子器件产品的可靠度下降到时，所经历的工作时间（3）中位寿命：指产品的可靠度降为50%时的寿命（4）特征寿命：指产品的可靠度降为1/e时的寿命（5）LED的寿命：通常用“半衰期”即器件的光输出下降到起始值50%时的时间作为LED的寿命。 用B50和L70来表示功率LED的寿命。L70（B50）表示功率LED比起初始值来，平均流明值下降到维持70%（50%）的时间。 9. 画出器件失效率随时间变化的曲线，说明曲线的各个阶段及其失 效原因。 答：曲线如图分为三个阶段： 第一个阶段称为早期失效或 老化阶段，失效率较高，随工作时间的延长而迅速下降。造成早期 失效的原因大多属生产型缺陷，由产品本身存在的缺陷所致。 第二个阶段为有效寿命阶段，又称随机失效阶段，失效率很低且 很稳定，近似为常数，器件失效往往带有偶然性。 第三个阶段称耗损失效阶段，失效率明显上升，大部分器件相继出现 失效，耗损失效都由于老化、磨损和疲劳等原因使器件性能恶化所致。 10. 伏安特性指流过PN结的电流随电压变化的特性，应将正、反向均包括在内。（1）反向击穿电压Vb：表示器件反向耐压高低的参数，通常是指一定漏电流下器件两端的反向电压值（2）反向电流Ir：给定反向电压下流过器件的反向电流值（3）正向电压Vf：指定正向电流下器件两端的正向电压值。作用：标志着结的体电阻及欧姆接触串联电阻的高低，可在一定程度上反应电极制作的好坏 12. 热管是依靠自身内部工质液相和气体二相变化来实现传热的导热元件，它是由高纯度的无氧铜管及铜丝网或铜粉烧结物组成，内充液体为工作介质。当受热端将工作液相蒸发成气相，气流经过中空管道流到冷却端，冷却后将工作流体凝结成液相，冷凝液借助于铜丝网或铜粉烧结物的毛细组织吸回受热端，完成吸热-放热循环，可在一定温差下将热量传导出。具有重量轻、结构简单、热传输量大、耐用寿命长、导热能力强等优点。回路热管比单管热管效率更高且不受位置影响。
第一章、半导体器件（附答案） 一、选择题 1．PN 结加正向电压时，空间电荷区将 ________ A. 变窄 B. 基本不变 C. 变宽 2．设二极管的端电压为 u ，则二极管的电流方程是 ________ A. B. C. 3．稳压管的稳压是其工作在 ________ A. 正向导通 B. 反向截止 C. 反向击穿区 4．V U GS 0=时，能够工作在恒流区的场效应管有 ________ A. 结型场效应管 B. 增强型 MOS 管 C. 耗尽型 MOS 管 5．对PN 结增加反向电压时，参与导电的是 ________ A. 多数载流子 B. 少数载流子 C. 既有多数载流子又有少数载流子 6．当温度增加时，本征半导体中的自由电子和空穴的数量 _____ A. 增加 B. 减少 C. 不变 7．用万用表的 R × 100 Ω档和 R × 1K Ω档分别测量一个正常二极管的正向电阻，两次测量 结果 ______ A. 相同 B. 第一次测量植比第二次大 C. 第一次测量植比第二次小 8．面接触型二极管适用于 ____ A. 高频检波电路 B. 工频整流电路 | 9．下列型号的二极管中可用于检波电路的锗二极管是： ____ A. 2CZ11 B. 2CP10 C. 2CW11 10．当温度为20℃时测得某二极管的在路电压为V U D 7.0=。若其他参数不变，当温度上 升到40℃，则D U 的大小将 ____ A. 等于 B. 大于 C. 小于 11．当两个稳压值不同的稳压二极管用不同的方式串联起来，可组成的稳压值有 _____ A. 两种 B. 三种 C. 四种 12．在图中，稳压管1W V 和2W V 的稳压值分别为6V 和7V ，且工作在稳压状态，由此可知输 出电压O U 为 _____ A. 6V B. 7V C. 0V D. 1V