当前位置:文档之家› ASAAC通用功能模块规范

ASAAC通用功能模块规范

ASAAC通用功能模块规范
ASAAC通用功能模块规范

Ministry of Defence

Interim Defence Standard 00-76 Issue 1 Publication Date 14 January 2005

ASAAC Standards

Part 1

Proposed Standards for Common

Functional Modules

NOTE

This standard is Provisional

If you have Difficulty with its

Application

Please Advise UK Defence

Standardization

AMENDMENT RECORD

Amd No Date Text Affected Signature and Date

REVISION NOTE

HISTORICAL RECORD

Defence

M R C. S IM

S TANDARDS P ROGRAMME M ANAGER 2Procurement Agency

D/DStan/21/76/1UK Defence Standardization

Rm 1138

Kentigern House

65 Brown Street

Glasgow G2 8EX

Direct line:0141 224 2585

Switchboard:0141 224 2531

Facsimile:0141 224 2503

e-mail:pdgsts1@https://www.doczj.com/doc/474960684.html,

14 December 2004

INTERIM DEFENCE STANDARD - INVITATION TO COMMENT

Defence Standard Number: 00-76 Part 1 Issue 1 INTERIM

Title: Standards for Common Functional Modules

The above Defence Standard has been published as an INTERIM Standard and is provisional because it has not been agreed by all authorities concerned with its use. It shall be applied to obtain information and experience on its application which will then permit the submission of observations and comments from users.

The purpose of this form therefore is to solicit any beneficial and constructive comment that will assist the author and/or working group to review the INTERIM Standard prior to it being converted to a normal Standard.

Comments are to be entered below and any additional pertinent data which may also be of use in improving the Standard should be attached to this form and returned to writer at the above address.

No acknowledgement to comments received will normally be issued.

NAME: Calum Sim SIGNATURE: Calum Sim BRANCH: STAN OPS SPM 2

1. Does any part of the Standard create problems or require interpretation:

YES NO If “yes” state under section 3:

a. the clause number(s) and wording;

b. the recommendation for correcting the deficiencies.

2. Is the Defence Standard restrictive:

YES NO If “yes” state in what way under section 3.

AN EXECUTIVE AGENCY OF THE MINISTRY OF DEFENCE

3. Comments, general or any requirement considered too rigid:

Page Clause Comments Proposed Solution

4. I/We agree that this Draft Standard, subject to my/our comments being taken into consideration, when published in final form will cover my/our requirements in full. Should you find my/our comments at variance with the majority, I/we shall be glad of the opportunity to enlarge upon them before final publication. Signature.................................................................Representing.................................................

Submitted by (print or type name and address)Telephone number:

Date:

Our Ref:

DSTAN Form 42

INTERIM DEF STAN 00-76 PART 1

Contents

0Introduction (5)

0.1Purpose (5)

0.2Document structure (5)

1Scope (7)

1.1Relationship with other ASAAC Standards (7)

2WARNING (7)

3Normative references (8)

4Terms, definitions and abbreviations (9)

4.1Terms and definitions (9)

4.2Abbreviations (9)

4.3Conventions used in this Standard (11)

4.3.1Special Fonts (11)

4.3.2Naming Conventions (11)

5CFM Definition (12)

5.1Generic CFM (12)

5.1.1Generic CFM – Description (12)

5.1.2Generic CFM – Requirements (14)

5.2Module Support Unit (15)

5.2.1Module Support Unit – Description (15)

5.2.2Module Support Unit – Requirements (15)

5.2.3Module Support Layer (18)

5.2.4Module Initialisation (19)

5.3Module Processing Capability (22)

5.3.1Data Processing Module (DPM) (24)

5.3.2Signal Processing Module (SPM) (24)

5.3.3Graphic Processing Module (GPM) (25)

5.3.4Mass Memory Module (MMM) (26)

5.3.5Power Conversion Module (PCM) (27)

5.3.6Network Support Module (NSM) (29)

5.4Network Interface Unit (NIU) and Routing Unit (RU) (30)

5.4.1NIU and RU Description (30)

5.4.2NIU and RU Requirements (31)

5.5Module Power Supply Element (31)

5.5.1Module Power Supply Element Description (31)

5.5.2Module Power Supply Requirements (32)

5.6Module Physical Interface (MPI) (32)

5.6.1MPI Description (32)

5.6.2MPI Requirements (32)

6Common Functional Module Interfaces (32)

6.1Module Logical Interface (MLI) (32)

6.1.1MLI Description (32)

6.1.2MLI Requirements (33)

6.2Module Physical Interface (MPI) (33)

6.2.1MPI Description (33)

6.2.2MPI Requirement (33)

6.3MOS Interface (33)

6.3.1MOS Interface Description (33)

6.3.2MOS Interface – Requirement (34)

7CFM System Support and Guidelines (34)

7.1Fault Management (34)

7.2Fault Detection (34)

7.3Fault Masking (34)

7.4Fault Confinement (35)

7.5Safety and Security (35)

7.5.1Safety35

iii

INTERIM DEF STAN 00-76 PART 1

7.5.2Security (35)

A.1.Data Processor Module (37)

A.2.Signal Processing Module (38)

A.3.Graphic Processing Module (39)

A.4.Mass Memory Module (40)

https://www.doczj.com/doc/474960684.html,work Support Module (40)

A.6.Power Conversion Module (41)

Figures

Figure 1 - ASAAC Standard Documentation Hierarchy (5)

Figure 2 - Functional representation of a generic CFM (14)

Figure 3 - IMA Common Functional Modules – Graphical Composition (24)

Figure 4 - The Power Supply Distribution functions of the PCM (29)

Figure 5 - Power Supply Element functions (32)

Figure 6 - Software Architecture Model - Three Layer Stack (35)

Tables

Table 1 - CFM Embedded Information - Read Only (16)

Table 2 - CFM Embedded Information - Read / Write (18)

Table 3 - PCM output characteristics (30)

Table 4 - PSE input voltage characteristics (33)

Table A-1 - Performance sheet for a DPM (39)

Table A-2 - Performance sheet for a SPM (40)

Table A-3 - Performance sheet for a GPM (41)

Table A-4 - Performance sheet for a MMM (42)

Table A-5 - Performance sheet for a NSM (42)

Table A-6 - Performance sheet for a PCM (43)

iv

INTERIM DEF STAN 00-76 PART 1

1

Introduction

0.1

Purpose

This document is produced under contract ASAAC Phase II Contract n°97/86.028.

The purpose of the ASAAC Programme is to define and validate a set of open architecture standards,concepts and guidelines for Advanced Avionics Architectures (A3) in order to meet the three main ASAAC drivers. The standards, concepts and guidelines produced by the Programme are to be applicable to both new aircraft and update programmes from 2005.The three main goals for the ASAAC Programme are:1. Reduced life cycle costs.2. Improved mission performance.3. Improved operational performance.

The ASAAC standards are organised as a set of documents including:

-

A set of agreed standards that describe, using a top down approach, the Architecture overview to all interfaces required to implement the core within avionics system.

-

The guidelines for system implementation through application of the standards.

The document hierarchy is given hereafter: (in this figure the document is highlighted)

Figure 1 - ASAAC Standard Documentation Hierarchy

INTERIM DEF STAN 00-76 PART 1

2

0.2 Document structure

The document contains the following sections:

- Section 1, scope of the document.- Section 2, normative references.

- Section 4, the terms, definitions and abbreviations.

- Sections 5 and 6 provide CFM concept definition, requirements and standards.- Section 7 provides guidelines for implementation of standards.

-

Performance sheets for each of the CFMs are attached to the end of the document. These sheets contain a list of attributes to be defined by the system designer and used by the CFM provider.

INTERIM DEF STAN 00-76 PART 1

3

1 Scope

This standard defines the functionality and principle interfaces for the Common Functional Module (CFM) to ensure the interoperability of Common Functional Modules and provides design guidelines to assist in implementation of such a CFM. It is one of a set of standards that define an ASAAC (Allied Standard Avionics Architecture Council) Integrated Modular Avionics System.

This definition of interfaces and functionality allows a CFM design that is interoperable with all other CFM to this standard, that is technology transparent, that is open to a multi-vendor market and that can make the best use of COTS technologies.

Although the physical organisation and implementation of a CFM should remain the manufacturer’s choice,in accordance with the best use of the current technology, it is necessary to define a structure for each CFM in order to achieve a logical definition of the CFM with a defined functionality. This definition includes:

-

The Generic CFM, which defines the generic functionality applicable to the complete set of CFMs. The generic functionality is defined in section 5.1.

-

The processing capability, which defines the unique functionality associated with each CFM type within the set. This functionality is defined in section 5.3.

-

The logical and physical interfaces that enable CFMs to be interoperable and interchangeable, these are defined in section 6.

-

The functionality required by a CFM to support the operation of the System is defined in section 7.

1.1 Relationship with other ASAAC Standards

The definition of the complete CFM is partitioned and is covered by the following ASAAC standards:

- CFM Mechanical properties and physical Interfaces – ASAAC Standards for Packaging.- CFM Communication functions – ASAAC Standards for Software.

- CFM Network interface – ASAAC Standards for Communications and Network.- CFM Software architecture – ASAAC Standards for Software.-

CFM Functional requirements – This document.

2 WARNING

The Ministry of Defence (MOD), like its contractors, is subject to both United Kingdom and European laws regarding Health and Safety at Work, without exemption. All Defence Standards either directly or indirectly invoke the use of processes and procedures that could be injurious to health if adequate precautions are not taken. Defence Standards or their use in no way absolves users from complying with statutory and legal requirements relating to Health and Safety at Work.

INTERIM DEF STAN 00-76 PART 1

3 Normative references

3.1The publications shown below are referred to in the text of this Standard. Publications are grouped and listed in alphanumeric order.

This European Standard incorporates by dated or undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this European Standard only when incorporated in it by amendment or revision. For updated references the latest edition of the publication referred to applies (including amendments).

A) References to published standards

[1] ISO/CD 1540Aerospace - Characteristics of aircraft electrical

systems - ISO/TC20/SC 1/WG 13 - Date: 20/04/1998

B) References to standards in preparation

[2] ASAAC2-STA-32410-001-SWG Issue 01Final Draft of Proposed Standards for Software1

[3] ASAAC2-STA-32420-001-HWG Issue 01Final Draft of Proposed Standards for

Communications/Network1

[4] ASAAC2-STA-32440-001-HWG Issue 01Final Draft of Proposed Standards for Packaging1

[5] ASAAC2-GUI-32450-001-CPG Issue 01Final Draft of Proposed Guidelines for System Issues –

Volume 2: Fault Management1

[6] ASAAC2-STA-32460-001-CPG Issue 01Final Draft of Proposed Standards for Architecture1

C) References to other documents

[7] The Common Object Request Broker Architecture and Specification, Issue 2.3, OMG2

[8] ASAAC2-GUI-32450-001-CPG Issue 01Final Draft of Proposed Guidelines for System Issues –

Volume 5: Time Management

D) References to documents from other organisations

[9] IEEE Std JTAG 1149.1 Boundary Scan3

3.2Reference in this Standard to any related document means in any Invitation to Tender or contract the edition and all amendments current at the date of such tender or contract unless a specific edition is indicated.

3.3In consideration of clause 3.2 above, users shall be fully aware of the issue and amendment status of all related documents, particularly when forming part of an Invitation to Tender or contract. Responsibility for the correct application of standards rests with users.

3.4DStan can advise regarding where related documents are obtained from. Requests for such information can be made to the DStan Helpdesk. How to contact the helpdesk is shown on the outside rear cover of Def Stans.

1 Published by: Allied Standard Avionics Architecture Council

2 Published by: Object Management Group

3 Published by: IEEE

4

INTERIM DEF STAN 00-76 PART 1

5

4

Terms, definitions and abbreviations

4.1

Terms and definitions

Use of “shall”, “should” and “may” within the standards observe the following rules:

- The word SHALL in the text expresses a mandatory requirement of the standard.

-

The word SHOULD in the text expresses a recommendation or advice on implementing such a

requirement of the standard. It is expected that such recommendations or advice will be followed unless good reasons are stated for not doing so.

-

The word MAY in the text expresses a permissible practice or action. It does not express a requirement of the standard.

Open System :

A system with characteristics that comply with specified, publicly maintained, readily

available standards and that therefore can be connected to other systems that comply with these same standards.

4.2

Abbreviations

2D Two Dimensional 3D Three Dimensional

A3Advanced Avionics Architecture AGT Absolute Global Time ALT Absolute Local Time

APOS Application to Operating System Interface ASAAC Allied Standard Avionics Architecture Council BIT Built-in Test CBIT Continuous BIT

CFM Common Functional Module

CORBA Common Object Request Broker Architecture COTS Commercial Off The Shelf CRC Cyclic Redundancy Check dc Direct Current

DPM Data Processing Module DSP Digital Signal Processor EDAC Error Detection And Correction FFT Fast Fouriert Transformation FIR Finite Impulse response Filter

FMECA

Fault Mode Effect and Criticality Analysis

INTERIM DEF STAN 00-76 PART 1

GPM Graphic Processing Module

GSM Generic System Management

HW Hardware

HDD Head-Down Display

HMD Helmet Mounted Display

HUD Head-Up Display

IBIT Initiated BIT

ID Identification

IDL Interface Definition Language

IEEE Institute of Electrical and Electronics Engineers IFFT Inverse Fast Fourier Transformation

IMA Integrated Modular Avionics

ISO International Standards Organisation

ITM Integrated Test and Maintenance

JTAG Joint Test Action Group

MC Module Controller

MIS Module Initialisation Support

MLI Module Logical Interface

MMM Mass Memory Module

MOS Module Support Layer to Operating System Interface MPI Module Physical Interface

MSL Module Support Layer

MSU Module Support Unit

MTP Maintenance Test Port

N/A Not Applicable

NIU Network Interface Unit

NSM Network Support Module

OMG Object Management Group

O/P Output

OS Operating System

6

INTERIM DEF STAN 00-76 PART 1

OSL Operating System Layer

PBIT Power-up / power-down BIT

PCM Power Conversion Module

PCU Power Conversion Unit

PE Processing Element

PMS Power Management System

PSA Power Switch Array

PSE Power Supply Element

PU Processing Unit

RC Reference Clock

RLT Relative Local Time

RTBP Runtime Blueprints

RU Routing Unit

SPM Signal Processing Module

TC Transfer Connection

TLS Three Layer Stack

Vdc Voltage dc

4.3 Conventions used in this Standard

The Interface Definition Language (IDL) as defined in the Common Object Request Broker Architecture (CORBA) 2.3 is used to express the MOS services as programming language independent services in this document. Fore more details refer to [7] .

The conventions used in this document are as follows:

4.3.1 Special Fonts

Words that have a special meaning appear in specific fonts or font styles. All code listings, reserved words and the name of actual data structures, constants, and routines are shown in Courier.

4.3.2 Naming Conventions

Parameter and variable names contain only words with lower case letters, which are separated by underscore.

Example:vc_message

NOTE: Upper and lower case letters are treated as the same letter.

7

INTERIM DEF STAN 00-76 PART 1

5 CFM Definition

The Common Functional Modules (CFMs) are line replaceable items and provide an ASAAC IMA system with a computational capability, network support capability and power conversion capability. The following set of modules have been defined for use within an IMA core processing system:

- Signal Processing Module (SPM).

- Data Processing Module (DPM).

- Graphics Processing Module (GPM).

- Mass Memory Module (MMM).

- Network Support Module (NSM).

- Power Conversion Module (PCM).

This set of CFMs complies with the generic CFM format defined in this section.

It is assumed that a System Design Specification will be raised for each specific project implementation in which the detailed performance requirements for each CFM will appear.

5.1 Generic CFM

5.1.1 Generic CFM – Description

The internal architecture of each CFM consists of a set of functional elements that are applied to each CFM implementation. These are shown graphically in Figure 2 and are detailed below. All functions, with the exception of the Processing Unit, are generic to each CFM type.

8

INTERIM DEF STAN 00-76 PART 1

9

Links to Network

Power

Figure 2 - Functional representation of a generic CFM

(For PCM and NSM refer to Figure 3)

-

The Module Support Unit (MSU) controls and monitors the module and provides common functions such as Built-in-Test (BIT) control, module initialisation, time management, status recording/reporting and support for MLI (section 6), system management and debugging.

-

The Processing Unit (PU) provides the specific function of a CFM, for example data processing, signal processing, mass storage. These are defined in section 5.3.

-

The Module Physical Interface (MPI) defines the physical characteristics of the module and implements the mechanical, optical, electrical and cooling interfaces. These are detailed in section 6 and are fully defined in the ASAAC Standards for Packaging [4] .

-

The Routing Unit (RU) provides the internal communications capability of the CFM and interconnects the Network Interface Unit (NIU) with the Processing Unit (PU) and the Module Support Unit (MSU). The RU also provides a direct coupling between a network input link and a network output link. The RU is controlled by the MSU.

-

The Network Interface Unit (NIU) performs the external communications capability by interfacing the off-module network with the module internal data paths implemented by the Routing Unit. The NIU supports the implementation of the communication part and the Network properties part of the Module Logical Interface (MLI). These are defined in the ASAAC Software Standard [2] and the ASAAC Standards for Communications and Network [3] respectively. It also supports network configuration in conjunction with the MSU.

-

The Power Supply Element (PSE) converts the external supply voltage into the appropriate internal supply voltages. Consolidation of redundant multiple power inputs shall also be provided by the PSE.The power supply architecture is defined in the ASAAC Standards for Architecture [6] .

INTERIM DEF STAN 00-76 PART 1

10

The CFM shall comprise hardware components, that implement the mechanical and electrical functionality and the physical interfaces of the CFM and software components collectively termed the “Module Support Layer” (MSL). The MSL provides, in conjunction with the hardware, the functional requirements and logical interfaces defined in the ASAAC Standards identified in section 1.1.The interfaces for the CFM are as follows and are detailed in section 6:

-

The Module Physical Interface (MPI), which defines the physical properties of the CFM including the mechanical, optical, electrical and cooling interfaces.

-

The Module Logical Interface (MLI), which defines the logical communication and command interface of the CFM.

-

The interface between the Module Support Layer (MSL) and the Operating System, the MOS, which provides generic, technology independent access to the low-level resources of a CFM and the communications interface to the other CFMs.

5.1.2 Generic CFM – Requirements

All CFMs designed to this standard shall meet the following requirements:

-

Have all set of functional elements as shown in Figure 2 for DPM, SPM, MMM and GPM. For PCM and NSM refer to Figure 3.

- Provide open system (see for definition 4.1) compliant processing hardware,

-

Promote insertion and use of commercial and military standards and technologies, and the reuse of software.

-

Provide integrated diagnostics (built-in test) and fault isolation means to support fault tolerance, failure management, reconfiguration and maintenance.

- Conform to the Module Physical Interface (MPI) definition [4] and section 5.6.

-

Support at least one input and one output link to the network. The number of links will be dependent on the module type and system implementation.

-

Comply with the MOS interface definition and provide the required supporting software in the MSL. This software must also meet the requirements defined in the ASAAC Standards for Software [2] . The NSM is exempt from this requirement.

-

Provide the common communication services, within the MOS interface, to allow access to the network resources [2] .

- Comply with the MLI definition. Note, that the NSM shall comply to the appropriate sub-set [2] .- Be programmable in high-level languages.

-

Time synchronisation, for more details see reference [8] . Note that the NSM and MMM have additional time distribution capability.

- Ensure internal communication bandwidth is compatible with external communication.

-

Comply with the Power Supply Architecture Specified in the ASAAC Standards for Architecture [6] :- Provide the second stage of the power supply architecture.

-

Be capable of operating in a fault tolerant configuration, i.e. it shall be possible to consolidate power supplies of a CFM (with the exception of the PCM) from two or more PCMs.

INTERIM DEF STAN 00-76 PART 1

11

5.2 Module Support Unit

This section covers the generic functionality provided by the MSU.

5.2.1 Module Support Unit – Description

The module support functionality is to be provided by the logical element the MSU. The MSU controls and monitors all activities for a DPM, SPM, GPM and MMM. The MSU provides all functions and services required for system management, external and internal communications and module management.

Guidelines for these functions are provided in the ASAAC Standards for Software [2] . In order to achieve the flexibility to control different types of modules a general-purpose processor called a Module Controller (MC)may be used.

5.2.2 Module Support Unit – Requirements

The services and capabilities, which shall be provided by the MSU, are described in the following sections.5.2.2.1

CFM Embedded Information

Each CFM shall contain information regarding particular characteristics of the CFM itself. This information shall be located in non-volatile storage to ensure no loss of information caused by removal of power.The information to be stored shall be distinguished as follows:

-

Read-Only is information that, after definition and programming, cannot be altered during operational use. The original manufacturer shall be the only one who is capable of programming or modifying these data. This constitutes data such as the manufacturers identity, CFM type, production batch number etc.that reflect the identity of the CFM. The required retrievable information are listed in Table 1.

-

Read/Write is information that can be updated whenever the module is operational. This constitutes data such as the hours of operation, executed maintenance activities, operational log, etc. that reflect the operational history of the CFM. The required information that shall be available is listed in Table 2. Fault Logging is considered separately in section 5.2.2.3.

The information with read-only access shall be accessible using the following methods:

- By interrogation of the Maintenance Test Port, a function covered in detail in section 5.2.2.6.-

By use of the MOS services, defined in the Software Standard, reference [2] .

Table 1 - CFM Embedded Information - Read Only

Name

Definition

Type

Length in Bytes Scope

Accessed Via

manufacturer_id Manufacturer's ID String 30

Global

moduleInfo/MTP serial_id

Serial ID

unsigned Short Specific to a single manufacturer

moduleInfo/MTP

prod_batch_date Date of production (week: 2year: 4)

String

6N/A MTP

cfm_type

Standard type of CFM (SPM,DPM, GPM, MMM, NSM, PCM)String 10Global moduleInfo/MTP

hw_version

Version of hardware

unsigned Short Specific to a single manufacturer MTP

msl_version

Version of MSL code stored on-CFM

unsigned Short

Specific to a single manufacturer

MTP

INTERIM DEF STAN 00-76 PART 1

12

Name Definition Type

Length in Bytes

Scope Accessed Via

standard_mpi_version_compliance Version of the MPI standard that the CFM is compatible with unsigned Short

Global MTP

standard_mos_ve rsion_

compliance Version of the MOS standard that the CFM is compatible with unsigned Short

Global moduleInfo/MTP

standard_mli_version_compliance Version of the MLI standard that the CFM is compatible with unsigned Short

Global moduleInfo/MTP

num_network

Number of different network interfaces on the CFM unsigned Short Specific to CFM moduleInfo/MTP

num_pe Number of PEs resident on the CFM

unsigned Short

Specific to CFM moduleInfo/MTP

For each Network interface resident on the CFM network_if_id

Network interface ID

unsigned Short Specific to CFM

moduleInfo/MTP

network_if_type

Type of network interface

(variable scope shall be across all possible network interface types)

String

10

Global moduleInfo/MTP

For each PE resident on the CFM pe_id

PE ID

unsigned Short Specific to CFM

moduleInfo/MTP

pe_type

Type of PE (variable scope shall be across all possible PE types)String

10

Global moduleInfo/MTP

pe_performance

Standardised performance available from PE in MOPS unsigned Long Specific to PE moduleInfo/MTP

pe_nonvol_memory

Amount of available non-volatile memory within each PE in Mbytes

unsigned Long

Specific to PE moduleInfo/MTP

pe_vol_memory

Amount of available volatile memory within each PE in Mbytes

unsigned Long

Specific to PE moduleInfo/MTP

pe_num_timer

Number of Timers within the PE

unsigned Short

Specific to PE moduleInfo/MTP

For each Timer within each PE resident on the CFM pe_timer_id

Timer ID

unsigned Short Specific to PE

moduleInfo/MTP

pe_timer_resolution

Resolution of the timer in nanoseconds unsigned Short

Specific to PE Timer

ModuleInfo/MTP

INTERIM DEF STAN 00-76 PART 1

13

Table 2 - CFM Embedded Information - Read / Write

Name

Definition

Type

Length In Bytes

Accessed via

operational_hou rs

Number of operational hours for the CFM (resolution = 1 minute)

unsigned Long

moduleStatus/MTP: read only

maintenance_log

Log describing the maintenance history of the CFM. A log entry needs to include:

Up to 256bytes per entry

readLogDevice:read only MTP: read/write

? Time-stamp (op hours)? Maintainer identity ?

Maintenance action identity

unsigned Long String String

30222system_log

Log describing the usage history of the CFM.A log entry needs to include:

32 bytes per entry

readLogDevice/MTP: read only writeLogDevice:write only

? Time-stamp (op hours)?

Relevant system identity

unsigned Long String 28cfm_status

Present status of the CFM; OK, Fail, PBIT in progress, IBIT in progress etc.

String

10

moduleStatus/MTP: read only

5.2.2.2 Built-in Test Capability (BIT)

Each CFM shall provide hardware and software resources to provide a level of fault detection within its own resources according to the following three BIT capabilities:

-

Power-up/Power-down BIT (PBIT) - Performs built-in test subsequent to module power-up. PBIT shall verify that the resources available on the CFM are fully operational before operational code is downloaded. Details on the initialisation are given in section 5.2.4.

-

Continuous BIT (CBIT) - CBIT shall be performed as a background activity during normal operation of the CFM.

-

Initiated BIT (IBIT) - IBIT shall be performed when initiated by another entity. After initiation of IBIT the normal operation of the CFM shall be interrupted and IBIT performed. After IBIT has terminated the CFM shall return to normal operation.

All BIT results, with the exception of a CBIT pass result, shall be reported to the Fault Log. The requirements for fault logging are given in section 5.2.2.3.5.2.2.3

Fault Logging

Each CFM shall provide a Fault Log implemented in non-volatile storage. Each entry in the Fault Log shall be time stamped.

The Fault Log shall be accessible for off-aircraft test and maintenance via the Maintenance Test Port (MTP),which is detailed in section 5.2.2.6.

Details on fault management are given in ASAAC guidelines for Fault Management, refer to [5] .

NOTE: The fault log should be readable without the rest of the module being powered. Therefore the test connector should provide power inputs directly to the memory hardware that is used to implement the log.

INTERIM DEF STAN 00-76 PART 1

14

5.2.2.4 Time Management

The CFM shall provide timers for the support of the System Time Management function as listed below.These shall be able to be synchronised from an external source using messages from the network.

-

Absolute global time (AGT):

This is the time of day, universally known both inside and outside the aircraft, is provided in terms of year, month, day, hour, minute and second, with fractional seconds if required. The System Design Specification shall specify the resolution and accuracy. The minimum resolution should be 1 ms.-

Absolute local time (ALT):

This time reference is local to the aircraft, and will have a higher resolution than that of absolute global time. Absolute local time shall be used for application synchronisation and scheduling. The ALT should have a resolution in the order of tens of microseconds and accuracy of the order of tens of

nanoseconds. The System Design Specification shall specify the precise resolution and accuracy.-

Relative local time (RLT):

Relative local time s of a higher resolution than the two other time references, and is used for close synchronisation of tightly coupled computing processes. The RLT should have a resolution of less than 1 microsecond. The precise resolution and accuracy for the RLT shall be specified by the System Design Specification.

The ASAAC time management concept is specified in ASAAC Standards for System and Fault Management [5] .5.2.2.5

Hours of Operation

Each CFM shall provide a non-volatile counter for time of operation. This counter shall maintain hours and minutes and shall have a range of at least 100 000 hours.

The hours of operation shall be accessible for purpose of test and maintenance via the Maintenance Test Port, as given in section 5.2.2.6. The format of hours of operation is given in Table 2.5.2.2.6

Maintenance Test Port (MTP)

Each CFM shall provide maintenance test port that allows access to internal resources for Inegrated Test and Maintenance (ITM) purpose. An interface compatible with IEEE P1149.1 (JTAG) may be used as a standard means of access.

As a minimum the following operations on the internal resources of the CFM shall be possible:

- Read Fault Log, Erase Fault Log.- Read hours of operation.- Activate PBIT, read PBIT results.- Activate IBIT, read IBIT results.- Download updated MSL software.

-

Access of on-module facilities for CFM debugging and monitoring.

The MTP shall not be part of the MPI but shall only give access after opening the cover of a CFM.

5.2.3 Module Support Layer

Each CFM shall include a set of software components that will be collectively termed the MSL. These

software components shall be responsible for supporting and implementing the various logical interfaces and functions required by the MSU and the CFM.

企业文件管理规定(制度范本、DOC格式)1.doc

公司文件管理规定(制度范本、DOC格式)1 四、公司文件管理规定 (一)总则 第一条为减少发文数量,提高办文速度和发文质量,充分发挥文件在各项工作中的指导作用,特制订本制度。 第二条文件管理内容主要包括:上级函、电、来文,同级函、电、来文,本厂上报下发的各种文件、资料。 第三条按照党政分工的原则,全厂各类文件分别由党委办公室和厂部办(以下简称两办)归口管理。 (二)收文的管理 第四条公文的签收 1.凡来厂公启文件(除厂领导订启的外)均由厂收发员登记签收(由上级或邮电局机要通讯员直送机要室的机要文件除外)后分别交两办机要秘书拆封。在签收和拆封时,收发员和机要秘书均需注意检查封口和邮戳。对开口和邮票撕毁函件应查明原因,对密件开口和国外信函邮票被撕应拒绝签收。 2.对上级机要部门发来的文件,要进行信封、文件、文号、机要编号的“四对口”核定,如果其中一项不对口,应立即报告上级机要部门,并登记差错文件的文号。 第五条公文的编号保管

1.两办机要秘书对上级来文拆封后应及时附上“文件处理传阅单”,并分类登记编号、保管。须由工厂承办或归档的厂领导亲启文件,厂领导启封后,也应分别交两办办理正常手续。 2.本厂外出人员开会带回的文件及资料应及时分别送交两办机要秘书进行登记编号保管,不得个人保存。 第六条公文的阅批与分转 1.凡正式文件均需分别由两办主任(或副主任)根据文件内容和性质阅签后,由机要秘书分送承办部门阅办,重要文件应呈送厂领导(或分管领导)亲自阅批后分送承办部门阅办,为避免文件积压误事,一般应在当天阅签完紧急文件要月即办。 2.一般函、电、单据等,分别由两办机要秘书直接分转处理。如涉及几个单位会办的文件,应同主办单位联系后再分转处理。 3.为加速文件运转,机要秘书应在当天或第二天将文件送到厂领导和承办部门如关系到两个以上业务部门应按批示次序依次传阅最迟不得超过2天(特殊情况例外)。 第七条文件的传阅与催办 1.传阅文件应严格遵守传阅范围和保密规定,不得将有密级的文件带回家、宿舍或公共场所,也不得将文件转借其他人阅看对尚未传达的文件不 得向外泄露内容。

热处理通用技术规范及作业指导书

热处理通用技术规范 编制: 审核: 批准:

热处理通用技术规范 1.目的 为确保公司生产的产品符合产品标准技术要求,根据公司质量手册和程序文件的规 定,特制定热处理通用工艺规范,用于指导热处理生产与过程控制。 2.适用范围 本规范明确了热处理生产的主要工艺和质量控制方式、方法、要求,适用于石油机械API SPEC7K转盘及其配件产品的各种热处理。 属于本公司的其他产品和外协产品的热处理也可参照本规范的基本要求执行。 3.主要热处理工艺 热处理是通过对工件的加热、保温和冷却,使金属或合金的组织结构发生变化,从而 获得预期的性能的操作工艺。热处理能最大限度的发挥材料潜力,改善和获得良好的机械 性能、加工性能、物理性能和化学性能等。 热处理作为生产过程特殊工序,在石油机械产品生产制造中有重要作用。 可以分为: a.整体热处理与表面热处理 整体热处理:如退火、正火、淬火、回火 表面热处理:如感应加热表面淬火、火焰加热淬火以及化学热处理(如表面渗碳、碳 氮共渗、氮化等) b.预先(或预备)热处理与最终热处理 预先热处理一般是为了获得良好的加工性能而采取的热处理工艺,如时效、退火(包 括去应力退火、球化退火等)、正火等,预先热处理有时也可以作为最终热处理。一般用于焊接结构件、铸件等。相对于最终热处理而言,某些重要、大截面钢件采用预先热处理(通常采用正火处理)是为使最终热处理产品有一个良好的组织保证。 3.1退火(Annealing) 将钢件加热到Ac3+30~50度或Ac1+30~50度或Ac1以下的温度后,一般随炉温缓慢冷却。主要是降低硬度,提高塑性,改善切削加工与压力加工性能;细化晶粒,改善力学 性能,为下一工序做准备;消除冷、热加工所产生的内应力。主要适用于合金结构钢、碳

公司文件格式规范

文件制式要求 公司文件的标准字体为黑体和仿宋,如无特殊说明,公司所有文件执行以下标准: 一、封面 标题局中,字体使用黑体小初号,加粗;副标题字体使用黑体一号。 二、标题 各种文件中,文件标题均使用黑体二号字,加粗;副标题用黑体四号字体,不加粗;标题和正文之间空一行。 三、LOGO 均放右上角,封面使用(图案+公司简称)字体黑体一号,文件正文使用(图案+公司全称)字体黑体小五号。 四、正文 一级标题以汉字(一、二、三等)标注为黑体四号字,加粗; 二级标题以括号内汉字(一)(二)(三)等标注为黑体小四号字,不加粗; 三级标题以数字(1、2、3等)标注为仿宋小四号字,正文为

仿宋小四号字,不加粗; 另外,正文前如有填写说明和目录的,请依序安排,其中,填写说明与目录的正文均使用黑体小四号字,不加粗。 五、行距 文件全文行距设置为倍行距,段落之间和条款之间空一行,各条款中的小标题无须空行。 六、段落开头 段落设置一般为首行缩进(2个字符),含条款的(如合同)为悬挂缩进。 七、页面设置 页边距上下均为厘米,左右为厘米,页眉距边界为厘米,页脚为厘米。 八、页眉页脚 文件的页眉为靠右公司LOGO;页脚格式正中均为数字“共几页-第几页”(如5-1),使用黑体小五号字。 九、图表 图表大小可根据需要设定,图表标题需用仿宋,五号字体,图表

内容中,标题栏需用仿宋,小四号字体,加粗,其它文字内容用仿宋,五号字体,图表的说明注解文字则用仿宋,小五号字体。 九落款 文件底部落款签名和日期使用黑体小四号字,加粗。 十其它 公司其它固定格式文件(公文、信纸、传真、邮件、合同等),请按附件格式样本(见附件)。 附录部门文件编号格式: 1、行政管理文件TR—XZ—年度后两位+月+顺序号(如 121001) 2、人事管理文件TR—HR—年度后两位+月+顺序号(如 121001) 3、财务管理文件TR—CW—年度后两位+月+顺序号(如 121001) 4、营销管理文件TR—YX—年度后两位+月+顺序号(如 121001) 5、资产管理文件TR—ZC—年度后两位+月+顺序号(如 121001) 6、金融管理文件TR—JR—年度后两位+月+顺序号(如121001)

产品外观检验标准范本

产品外观检验标准(通用) 1、目的: 确定通用成品外观标准,为公司品质控制提供标准的依据。 2、适用范围: 适用于我司外观检验的标准判定,另有客户特殊规定除外。 3、职责权限: 3.1品质部:负责本检验标准的制定与审核,产品的鉴定、检验之执行; 3.2工程部:负责品质问题的分析和改善活动的推行; 3.3生产部:负责产品的制造、过程检验和过程品质记录。 4、定义: 4.1异色点:产品表面出现的颜色异于周围的点。 4.2缩水:部分区域由于熔体压力不够,在该区域截面形成的凹坑。 4.3批锋:由于工艺或模具原因,在边缘分型面处所产生的废边。 4.3污点:表面形成的可擦除赃污。 4.4无感划伤:用指甲刮过划伤处,无段落感。 4.5有感划伤:用指甲刮过划伤处,有段落感。 4.6脏污:因模具、包装或操作等问题造成,分可擦出及不可擦出。 4.7气泡:因工艺原因内部出现的可见的空气泡。 5、工作程序 5.1目视检查的外观条件及位置: 检验条件:距离30cm~45cm,时间 5 S,光源检验照明度20-40W 位置:产品与平面呈45°,上下左右转动动在15°之内。 检验时间:一般在5-10秒以内。条件:不得在反光下检验表面。 5.2 外观区域划分 5.2.1 A区:正常目视第一眼可见面(样品的正面) 5.2.2B区:正常目视第一眼不可见面(左右两侧面,底面,背面,顶面) 5.2.3C区:产品内部,正常目视不可见面 5.3 成品外观检验项目:

6、对一些典型缺陷的描述 ●色点:肉眼观察难以区分长与宽的形状,测量时以其最大直径为其尺寸。 ●颗粒:在喷漆件表面上附着的细小颗粒。 ●阴影:在喷漆件或塑料件表面出现的颜色较周围暗的区域。 ●桔纹:在喷漆件或电镀件表面出现大面积细小的像桔子皮形状的起伏不平。 ●透底:在喷漆件表面出现局部的油漆层过薄而露出基体颜色的现象。 ●鱼眼:由于溶剂挥发速度不适而造成在喷漆件表面有凹陷或小坑。 ●多喷:超出图纸上规定的喷涂区域。 ●剥落:产品表面上出现涂层或镀层脱落的现象。 ●毛絮:油漆内本身带有的,或油漆未干燥时落在油漆表面而形成的纤维状毛絮。 ●色差:产品表面呈现出与标准样品(客户承认样品)的颜色的差异,称为色差。 ●光泽不良:产品表面呈现出与标准样品(客户承认样品)光泽不一致的情况。 ●手印:在产品表面或零件光亮面出现的手指印痕。 ●异色点:在产品表面出现的颜色异于周围的点。 ●多胶点:因模具方面的损伤而造成局部细小的塑胶凸起。 ●缩水:当塑料熔体通过一个较薄的截面后,其压力损失很大,很难继续保持很高的压力 来填充在较厚截面而形成的凹坑。 ●亮斑:对于非光面的塑料件,由于壁厚不均匀,在壁厚突变处产生的局部发亮现象。 ●硬划痕:由于硬物摩擦而造成产品表面有深度的划痕。 ●细划痕:没有深度的划痕。 ●飞边:由于注塑参数或模具的原因,造成在塑料件的边缘或分型面处所产生的塑料废边。 ●熔接线:塑料熔体在型腔中流动时,遇到阻碍物(型芯等物体)时,熔体在绕过阻碍物 后不能很好的融合,于是在塑料件的表面形成一条明显的线,叫做熔接线。 ●翘曲:塑料件因内应力而造成的平面变形。 ●顶白/顶凸:由于塑料件的包紧力大,顶杆区域受到强大的顶出力所产生的白印或凸起。 ●填充不足:因注射压力不足或模腔内排气不良等,使融熔树脂无法到达模腔内的某一角 落而造成的射料不足现象。 ●银条:在塑料件表面沿树脂流动方向所呈现出的银白色条纹。 ●流纹:产品表面以浇口为中心而呈现出的年轮状条纹。 ●烧焦:在塑料件表面出现的局部的塑料焦化发黑。 ●边拖花:因注射压力过大或型腔不平滑,脱模时所造成边缘的擦伤。 ●破裂:因内应力或机械损伤而造成产品的裂纹或细小开裂。 ●龟裂:橡胶件由于环境老化而造成在产品表面上有裂纹。 ●浇口:塑料成型件的浇注系统的末端部分。 ●搭桥:在导电胶转角位置,出现上面胶是连接着,但下面胶没有连着而出现空洞的现象。 ●补伤:对导电胶上已损坏的部位进行修补。 ●油渍:在产品表面所残留的油污。

公司文件管理规定

公司文件管理规定 第一章总则 第一条为使公司的文件管理工作实现规范化、制度化、科学化,提高办文速度和发文质量,充分发挥文件在各项工作中的指导作用,特制定本规定。 第二条文件管理的范围包括:上级下发文件、公司各类制度文件、外部传真文件、政策指导类文件、各类合同文件等。本规定中,公文指公司内外部发文文件,是具有法定效力和规范体式的文书。 第二章公文管理 第三条公文管理指公文的办理、管理、整理(立卷)、归档等一系列相互关联、衔接有序的工作。公文管理应当坚持实事求是、精简、高效的原则,做到及时、准确、安全,必须严格执行国家保密法律、法规和其他有关规定。 第四条公文种类与应用范围 1.公文种类:决定、公告、通知、通报、报告、请示、批复、意见、函、会议纪要等。 2.公司常用文种应用范围 2.1决定:适用于对重要事项或重大行动做出安排,奖惩有关部门及人员;变更或者撤销不适当的决定事项。 2.2公告:适用于对外宣布重要事项或法定事项。一般基层单位不宜用公告的形式随意制发公告。 2.3通知:适用于转发上级单位和不相隶属单位的公文;传达要求公司各部门执行和需要有关单位阅知的事项。

2.4通报:适用于表彰先进,批评错误,传达重要精神或情况。 2.5报告:适用于向上级单位汇报工作,反映情况,提出意见或建议,答复上级单位的询问。 2.6请示:适用于向上级单位提出请求,并要求回复的公文。 2.7批复:适用于答复下级单位的请示事项。 2.8意见:适用于上级单位或主管部门对重要问题提出见解和处理办法。 2.9函:适用于平行单位或不相隶属单位之间,相互商洽和联系工作、询问和答复问题,请求批准和答复事项。 2.10会议纪要:适用于记载、传达会议情况和议定事项。 第五条职责权限 1.综合部是行政公文的管理部门,负责公文的审核、印制、发放及收文登记、督办、归档保管。涉及公司性文件由综合部负责拟稿,专业性文件原则上由相关业务部门拟稿。 2.行政公文由总经理签发,制度规定类文件由法人代表签发,公司各部门负责公文的宣传、贯彻、落实。 3.各部门不得自行向上、向下发送正式公文。 第六条发文规则 1.发文应当确有必要,注重效用;发文根据隶属关系和职权范围确定,不得越级请示和报告。 2.发文统一使用公司的红头文件格式,由拟稿部门领导核稿后送综合部审核打印,经总经理签发后由综合部成文。如管理制度、公司机构设置等需董事会决定的

公司通用文件格式规范

公司通用文件格式规范 Prepared on 24 November 2020

公司文件格式规范 团结勤力创新诚信 说明书 XXXXXXX有限公司 XXX年XX月XX日

关于公司制度文件格式的说明 ——请各部门根据模板修改相应格式公司的标准字体为黑体和楷体,如无特殊说明,公司所有文件执行以下标准: 第一条封皮 凡有封皮的文本,请依据模板设置封皮,并在管理部备案。 第二条文件标题 各种文件中,文件标题均使用黑体二号字,加粗;副标题用黑体四 号字体,不加粗;标题和正文之间空一行。 第三条正文字体 第四条行距、段落间距 文件全文行距设置为单倍行距,段落之间和条款之间空一行,各条 款中的小标题无须空行。 第五条缩进 段落设置一般为首行缩进(2个字符),含条款的(如合同)为悬 挂缩进。 第五条页面设置 页边距上下均为厘米,左右为厘米,页眉距边界为厘米,页脚为厘 米。 第六条页眉页脚 页眉为靠左“中山市智朗/康宜居电器有限公司”,靠右“团结勤力 创新诚信”;

页脚格式均为“第X页,共X页”,页眉、页脚均使用楷体五号字, 不加粗,带格式线。 第七条图表 图表大小可根据需要设定,图表标题需用楷体_GB2312,五号字 体,图表内容中,标题栏需用楷体_GB2312,小四号字体,加粗, 加入标准淡绿色底纹,其它文字内容用楷体_GB2312,五号字体, 图表的说明注解文字则用楷体_GB2312,小五号字体。 第九条落款 文件底部若需要落款,签名和日期请使用黑体小四号字,不加粗,日 期必须为年月日,如:2012年02月29日 第十条审核 如需外发其他部门的文件,格式如下: 发:各部门、车间 抄报:董事长、总经理 印发份数:21份其中存档份数:1份 编制:审核:批准: 无需外发其他部门的文件,格式如下: 编制:审核:批准: 第十条其它固定格式文件 公司其它固定格式文件(公文、通告、通知、合同等),请按附件格 式样本(见附件)。

紧固件通用技术标准最新版本

浙江乐苏金属材料有限公司企业标准 紧 固 件 通 用 技 术 条 件

前言 本标准的编定遵循了GB/T1.1-2000和GB/T1.3-2002《标准化工作导则第2部分:标准中规范性技术要素内容的确定方法》中有关企业标准编写的基本规定. 本标准替代原QJ/SP 1.7K-1999《紧固件通用技术条件》 本标准由浙江乐苏金属材料有限公司提出. 本标准起草单位: 浙江乐苏金属材料有限公司质控部. 本标准起草人:刘箫.

紧固件通用技术条件 1.范围 本标准规定了紧固件的尺寸、要求、抽样、试验方法及标志、包装、运输和贮存. 本标准适用于公司有关产品紧固件螺钉、螺母、垫圈、铆钉、除压力锅柄座以外的柄座的进货检验. 2.下列文件中的条款通过本标准的引用而成为本标准的条款.凡是注 日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本.凡是不注日期的引用,其最新版本适用于本标准. GB/T 2828-1987 逐批检查计数抽样程序及抽样表 QB/T 3826-1999 轻工产品金属镀层和化学处理层的耐腐 蚀实验方法.中性盐雾试验(NSS)法QB/T 3832-1999 轻工产品金属镀层腐蚀试验结果的评价. 3.尺寸 按产品图样或其他有关技术文件. 4.要求 4.1.面质量 4.1.1.表面不应有毛刺、裂纹. 4.1.2.应洁净,不许有油污迹. 4.1.3.表面处理层应均匀,无露底现象.

4.1.4.螺纹部分应无跳格或粗细不均匀现象. 4.1.5抛光或滚光产品应光亮. 4.2.紧固件经装配紧固后应牢固可靠. 4.3.防腐性 经中性盐雾试验,耐腐蚀等级3级以上. 5.抽样 5.1.表面质量按GB/T 2828特殊检查水平S-4、采用一次抽样方案, 合格质量水平AQL=6.5进行检查. 5.2.尺寸及4.2的检测按GB/T 2828特殊检查水平S-2,一次抽样方 案,合格质量水平AQL=10进行检查. 5.3.防腐性为型式项目,刚开始生产及正常生产时每半年试验一次, 试验样品为三只. 6.试验方法 6.1.用精度为0.02㎜的深度游标尺寸和角度板及其他相应的检测工 具检测. 6.2.表面质量用目视检验. 6.3.紧固件经装配后用手感检测其牢固可靠性. 6.4.防腐性试验:按QB/T 3826-1999标准(NSS)进行六小时试验,取 除检验QB/T 3832-1999第5.6评价. 7.标志、包装、运输和贮存 7.1标志 包装上应有标志,包括下列内容

公司内部文件格式标准规范

公司公文格式标准规范(试行) 1.目的 为规范公司内部公文格式,提高公司内部文件管理质量。 2.适用范围 公司各部门 3.内容 3.1公司文件格式要求: 3.1.1红头文格式 3.1.1.1文头的字体:一号黑体字、加粗、红色、居中、字符间距为1磅 3.1.1.2发文字号的字体:四号宋体、黑色 3.1.1.3标题的字体:三号黑体字、加粗、黑色、居中 3.1.1.4主送机关的字体:四号宋体、黑色 3.1.1.5正文的字体:四号宋体、黑色、首行缩进2个字符、1.5倍行距 3.1.1.6附件的字体:四号宋体、黑色、首行缩进2个字符、1.5倍行距 3.1.1.7作者的字体:四号宋体、黑色、右对齐 3.1.1.8日期的字体:四号宋体、黑色、右对齐,“零”可写为“○” 3.1.1.9注释的字体:小四号宋体、黑色 3.1.1.10主题词的字体:三号黑体、黑色、加粗 3.1.1.11抄送机关的字体:四号宋体、黑色 3.1.1.12印发说明的字体:四号宋体、黑色印章上不压正文,下压日期 3.1.1.13所有红头文件在发布之后将原件交由综合办公室部并进行统一编号保管 3.1.2规章制度文格式 3.1.2.1文件标题: 各级标题均用阿拉伯数字(1,1.1,1.1.1)区别,大标题为黑体三号加粗,一级标题字体用黑体四号字加粗,二级标题用楷体GB-2312小四号字加粗,三级、

四级标题用仿宋体小四号字,一般不用宋体字标注小标题,也不用“加粗”的方式标注小标题 3.1.2.2文件正文:宋体小四号字,正文强调部分内容为宋体小四号字加粗3.1.2.3发文单位/发文时间/落款/日期:宋体小四号字 3.1.2.4主题词/呈/发:宋体小四号字 3.1.2.5行间距:1.5倍 3.1.2.6页边距:上下各为2.54㎝,左右各为3.17㎝ 3.1.2.7页眉顶端距离:1.5cm,并添加公司logo及公司全称(宋体小四),页脚底端距离:1.75cm,页码居中(Times New Roman 小五) 3.1.2.8公司简称:在文件正文内可简称“**公司” 3.1.2.9公司全称:在落款、合同文本等情形必须用全称 3.1.3 企业常用公文(规定、报告、总结、通报、决议、指示、条例、公告、通告、决定、意见、报告、请示、批复、函、会议纪要等)格式 3.1.3.1封面标题:黑体小初号、加粗、字符间距为1磅 3.1.3.2封面副标题:黑体一号 3.1.3.3标题:二号黑体字、加粗、黑色、居中 3.1.3.4段落标题: 一级标题以汉字“一、”标注为宋体小四号字,加粗; 二级标题以汉字“(一)”标注为宋体小四号字,不加粗; 三级标题以汉字“1.”标注为宋体小四号字,不加粗; 四级标题以数字加括号“(1)”标注为宋体小四号字,不加粗 3.1.3.5正文的字体:小四号宋体、黑色、首行缩进2个字符、1.5倍行距3.1.3.6附件的字体:小四号宋体、黑色、首行缩进2个字符、1.5倍行距3.1.3.7发文单位:小四号宋体、黑色、右对“日期上”居中 3.1.3.8日期的字体:小四号宋体、黑色、右空4字,“零”可写为“○” 3.1.3.9注释的字体:小四号宋体、黑色 3.1.3.10主题词的字体:四号黑体、黑色、加粗 3.1.3.11抄送机关的字体:小四号宋体、黑色 3.1.3.12行间距、页边距、页眉页脚距离同制度文格式 3.1.4请示文格式

电子设备产品外观检验规范标准

修改记录 制订部门:品管部 制作: 审核: 批准: 1.0范围 本标准规定了xxx科技有限公司品牌,以及其他无客户特殊外观要求的品牌的盒式产品、一体化机箱和手持类产品的外观检验标准。在本标准中未出现的缺陷种类参照现有关规定执行或参考与它相似(影响程度相当)的项目执行。 本标准可用于指导结构件供应商生产、装配检验,xxx科技有限公司装配检验等环节对xxx 科技有限公司产品的外观检验和验收。 如果某个产品的客户对外观有特殊要求,则按照客户提供的外观标准来进行检验和验收。本标准对一些可以接受的表面外观缺陷进行限制。

2.0术语和定议 产品表面等级根据重要程度,可划分为A级面、B级面和C级面,具体定义如下: A级面B级面C级面表面等级的规定是产品的外观标准,对于产品在客户处使用时看不见的内部表面,如塑胶滑道等,不属于本标准规定范围。 表面等级的定义是以在最终客户处使用情况为条件而界定的。如果零件、部件、产品在后续装配、安装过程中被掩盖,则以被掩盖后的表面来定义;如果零件、部件、产品在后续装配、安装过程中有可能被掩盖也有可能不被掩盖,则按照不掩盖的表面来定义。 3.0检验条件 3.1光照要求 在自然光或光照度在500LX 的近似自然光下检验。对于40W的日光灯、检验距离要求是500mm。 3.2检验员的要求 检验者的视力或矫正视力不低于1.0,被检查表面和人眼视线呈45°角(图2).

3.3检验时间、距离和是否旋转的要求 A级面B级面C级面 检查时间(秒) 10 5 3 检查距离(mm) 450 450 600 是否旋转旋转不旋转不旋转 4.0 判定总则 可接收的A级面、B级面和C级面缺陷不能影响装配和功能,否则仍判不合格。 同一表面同一区域缺陷不能聚集过多。即在直径100mm的圆内,实际缺陷数量不能超过缺陷允收表规定的缺陷数量N 。 同一表面同一区域缺陷不能聚集过大。即实际测量结果不能大于缺陷允收表的要求。对于可累积计算的缺陷如长度L和面积S等,记录累积值(L=L1+L2+…Ln,S=S1+S2+…Sn)与缺陷允收表比较。对无法累积计算的缺陷如高度H,宽度W,直径D等,记录最大的测量值与缺陷允收表比较。 缺陷允收表解释: 缺陷允收表规定了在直径100mm的圆内各类缺陷的允收标准,两个缺陷点间的距离要大于50mm。 缺陷允收表中的N代表缺陷数量;L代表缺陷长度;W代表缺陷宽度;H代表缺陷高度;D 代表缺陷直径;S代表缺陷面积,面积的单位是mm2。本文中涉及到的长度,宽度、粗细、高度、直径的单位是mm。 缺陷允收表中关于缺陷的记录解释如图 3 所示: 缺陷允收表中关于缺陷的记录解释 5 .0 塑胶件外观标准

《标签符合性测试通用技术规范》国家标准(征求意见稿)

《标签符合性测试通用技术规范》 国家标准(征求意见稿)编制说明 一、任务来源 国家标准《标签符合性测试通用技术规范》于2012年列入国家标准委国家标准制、修订计划,计划号为“20121521-T-424”,由中国标准化研究院组织起草工作。 二、目的和意义 本标准是规定了执行标签符合性测试的通用技术要求。本标准适用于所有产品标签的符合性测试,通过对执行标签符合性测试过程中所涉及到的人员、设施设备、测试要求、测试实施、测试结果的判定、原始记录、测试报告等方面进行详细的规范,对相关组织开展符合性测试,得出测试报告,具有一定的指导意义。 三、标准制定过程 1、调研和材料收集阶段 国家标准计划下达后,中国标准化研究院组建了标签符合性测试系列标准工作组,确定了工作计划,标准起草组成员便从各种渠道大量收集与本标准有关的信息和资料,为本标准的制定做好充分准备。 2、分析、比较和研究 标准起草组对我国现阶段与符合性测试相关的法律、法规、标准等文件进行了认真的分析、比较和研究,特别是针对我国已有的开展标签符合性测试技术相关标准文件进行了分析整合。 3、形成标准草案

起草组收集了有关资料,借鉴国内外各类检查机构测试流程和能力要求规范以及标签检测类实验室实际工作经验,形成国家标准草案文本。 4、工作组集中工作 标签符合性测试通用技术规范标准工作组在标准草案的基础上,在工作组内以工作会形式开展阶段性集中工作,组织标准用户单位、认证机构、以及标签符合性测试领域专家进行符合性测试系列标准的集中工作和研讨。 5、形成征求意见稿 工作组对标准文本进行了逐条讨论和修订完善,并对其中存疑的内容进行讨论并征询多方建议,在此基础上,于2016年5月形成征求意见稿。 6、起草编制说明 在标签符合性测试通用技术规范标准工作组成员认真审查了工作组内对标准的意见处理后,在标准内容上达成共识,并与本标准的征求意见稿同步完成了标准的编制说明。 四、标准主要内容 本标准规定了执行标签符合性测试的通用技术要求。本标准适用于所有产品标签的符合性测试。 本标准从人员、设施设备、测试要求、测试实施、测试结果的判定、原始记录、测试报告等方面对开展符合性测试的技术要求进行了详细的阐述和说明。为执行性符合性测试,得出测试报告,提供了详

公司文件格式规范

公司文件格式规范 Document number:BGCG-0857-BTDO-0089-2022

文件制式要求 公司文件的标准字体为黑体和仿宋,如无特殊说明,公司所有文件执行以下标准: 一、封面 标题局中,字体使用黑体小初号,加粗;副标题字体使用黑体一号。 二、标题 各种文件中,文件标题均使用黑体二号字,加粗;副标题用黑体四号字体,不加粗;标题和正文之间空一行。 三、LOGO 均放右上角,封面使用(图案+公司简称)字体黑体一号,文件正文使用(图案+公司全称)字体黑体小五号。 四、正文 一级标题以汉字(一、二、三等)标注为黑体四号字,加粗; 二级标题以括号内汉字(一)(二)(三)等标注为黑体小四号 字, 不加粗;

三级标题以数字(1、2、3等)标注为仿宋小四号字,正文为 仿宋小四号字,不加粗; 另外,正文前如有填写说明和目录的,请依序安排,其中,填写说明与目录的正文均使用黑体小四号字,不加粗。 五、行距 文件全文行距设置为倍行距,段落之间和条款之间空一行,各条款中的小标题无须空行。 六、段落开头 段落设置一般为首行缩进(2个字符),含条款的(如合同)为悬挂缩进。 七、页面设置 页边距上下均为厘米,左右为厘米,页眉距边界为厘米,页脚为厘米。 八、页眉页脚 文件的页眉为靠右公司LOGO;页脚格式正中均为数字“共几页-第几页”(如5-1),使用黑体小五号字。 九、图表

图表大小可根据需要设定,图表标题需用仿宋,五号字体,图表内容中,标题栏需用仿宋,小四号字体,加粗,其它文字内容用仿宋,五号字体,图表的说明注解文字则用仿宋,小五号字体。 九落款 文件底部落款签名和日期使用黑体小四号字,加粗。 十其它 公司其它固定格式文件(公文、信纸、传真、邮件、合同等),请按附件格式样本(见附件)。 附录部门文件编号格式: 1、行政管理文件TR—XZ—年度后两位+月+顺序号(如 121001) 2、人事管理文件TR—HR—年度后两位+月+顺序号(如 121001) 3、财务管理文件TR—CW—年度后两位+月+顺序号(如 121001) 4、营销管理文件TR—YX—年度后两位+月+顺序号(如 121001) 5、资产管理文件TR—ZC—年度后两位+月+顺序号(如 121001)

新1公司行文规范及管理办法

1公司行文规范及管理办法 为规范公司各种文件的起草、签发和提高公文质量,确定文件编号办法,为各种文件的收发、存档工作奠定基础;确定公司重要信息披露载体的格式、样式,树立公司管理形象。做到政令畅通,令行禁止,正确指导公司的各项工作,适应公司的快速发展特制定本办法。 通过此办法的实施,达到各种文件可追溯,各级文件有保管,全部文件受控的目的。 一、纸型、纸质 复印纸A4型(国际标准210mm×297mm), 厚度定量60—80g/㎡。 二、封面 文件材料10页以内的一般不加封面,确需加封面的材料可以加上,如规划、纲领性文件、规章制度、材料汇编等。封面可使用必要公司的统一VI形象(文字和徽标),但不宜用花边和图案。加封面的材料同时应加封底。 三、书写要求 (一)标题使用2号宋体加黑,顶行。 (二)副标题居中排列,使用3号宋、仿宋或楷体,但不与正文字体重复,破折号占2格。标题单独成行时,均无需标点。 (三)正文使用4号仿宋。每段文字前空两格,第2行起均顶格。不提倡正文内标题使用加粗或艺术字体,如行书、隶书、魏书、细圆体、综艺体、琥珀体、瘦金体等,以保持文面严肃、整洁。 (四)章节的排序为第一层“一”,第二层“(一)”,第三层“1、”,

第四层“(1)”,第五层“1)”。 (五)正文中表格一般作附件置后。小于文面半幅的,可随文就位,与正文同宽。表内字体同正文,字号可略小。 (六)数字除成文日期、部分结构层次序数和在词、词组、惯用语、缩略语、具有修辞色彩语句中作为词素的数字必须使用汉字外,应当使用阿拉伯数字。 四、落款、盖印 在正文后空两行,单位名称按印章全称。盖印,可不写单位名称。成文日期中“○”用插入符号里的几何图形,不能用阿拉伯数“0”。最后一个字离右边沿四格。盖印跨年月日,上2/3,下1/3,左右居中,端正清晰。 五、页面设置 上 2.0cm,下2.0 cm,左2.0 cm,右2.0 cm,页脚1.0 cm,行距28磅, 或每面排22行,每行排28个字。为避免最后一页只是几行占一页的现象,可适当收缩行距,使文件成为几张整页, 但收缩行距不宜小于20磅。双面印刷页码居外侧,单面印刷页码居右侧。 六、装订 一律左侧装订。钉离左侧边沿0.5cm,2个钉在上下各1/4处,钉垂直。 七、分类与编号 (一)文件分类 公司常用文件格式分为会议纪要、通知、通报、任命、其他管理制度、工作提案等,其中会议纪要不用文件编号,提取或说明时以某年某月某日(会议召开时间)及某领导(公司领导)主持的某某会(会

公司通用文件格式规范

团结勤力创新诚信 公司文件格式规范 说明书 XXXXXX)有限公司 XXX年XX月XX日

关于公司制度文件格式的说明 ——请各部门根据模板修改相应格式公司的标准字体为黑体和楷体,如无特殊说明,公司所有文件执行以下标准: 第一条封皮 凡有封皮的文本,请依据模板设置封皮,并在管理部备案。 第二条文件标题各种文件中,文件标题均使用黑体二号字,加粗;副标题用黑体四号字体,不加粗;标题和正文之间空一行。 第三条正文字体 各级标题均用阿拉伯数字(1. ,,)区别。一级标题为黑体四号字,加粗,二级标题 为黑体小四号字,不加粗,三级标题为楷体_GB2312小 四号字,加粗,正文为楷体_GB2312小四号字,不加粗;另外,正文前如有填写说明和目 录的,请依序安排,其中,填写说明与目录的正文均使用黑体小四号字,不加粗。 第四条行距、段落间距 文件全文行距设置为单倍行距,段落之间和条款之间空一行,各条款中的小标题无须空 行。 第五条缩进 段落设置一般为首行缩进(2 个字符),含条款的(如合同)为悬挂缩进。 第五条页面设置 页边距上下均为厘米,左右为厘米,页眉距边界为厘米,页脚为厘米 第六条页眉页脚 页眉为靠左“中山市智朗/康宜居电器有限公司” ,靠右“团结勤力创新诚信” ; 页脚格式均为“第X 页,共X 页”,页眉、页脚均使用楷体五号字,不 加粗,带格式线。

第七条图表 图表大小可根据需要设定,图表标题需用楷体_GB2312五号字体,图表内容中,标题栏需 用楷体_GB2312小四号字体,加粗,加入标准淡绿色底纹,其它文字内容用楷体_GB2312 五号字体,图表的说明注解文字则用楷体_GB2312小五号字体。 第九条落款 文件底部若需要落款,签名和日期请使用黑体小四号字,不加粗,日期必须为年月曰, 如:2012年02月29日 第十条审核 第十条其它固定格式文件 公司其它固定格式文件(公文、通告、通知、合同等),请按附件格式样本(见附件)。

公司内部文件格式标准规范

公司内部公文格式标准规范(试行) 1.目的 为规范公司内部公文格式,提高公司内部文件管理质量。 2.适用范围 总公司及子公司各部门 3.内容 3.1公司文件格式要求: 3.1.1红头文格式 3.1.1.1文头的字体:一号黑体字、加粗、红色、居中、字符间距为1磅3.1.1.2发文字号的字体:四号宋体、黑色 3.1.1.3标题的字体:三号黑体字、加粗、黑色、居中 3.1.1.4主送机关的字体:四号宋体、黑色 3.1.1.5正文的字体:四号宋体、黑色、首行缩进2个字符、1.5倍行距3.1.1.6附件的字体:四号宋体、黑色、首行缩进2个字符、1.5倍行距3.1.1.7作者的字体:四号宋体、黑色、右对齐 3.1.1.8日期的字体:四号宋体、黑色、右对齐,“零”可写为“○”

3.1.1.9注释的字体:小四号宋体、黑色 3.1.1.10主题词的字体:三号黑体、黑色、加粗 3.1.1.11抄送机关的字体:四号宋体、黑色 3.1.1.12印发说明的字体:四号宋体、黑色印章上不压正文,下压日期 3.1.1.13所有红头文件在发布之后将原件交由行政部并进行统一编号保管3.1.2规章制度文格式 3.1.2.1文件标题: 各级标题均用阿拉伯数字(1,1.1,1.1.1)区别,大标题为黑体三号加粗,一级标题为宋体四号字加粗,二级标题为宋体小四号字加粗,三级标题为楷体GB-2312小四号字加粗 3.1.2.2文件正文:宋体小四号字,正文强调部分内容为宋体小四号字加粗3.1.2.3发文单位/发文时间/落款/日期:宋体小四号字 3.1.2.4主题词/呈/发:宋体小四号字 3.1.2.5行间距:1.5倍(未定义文档网格) 3.1.2.6页边距:上下各为2.54㎝,左右各为3.17㎝ 3.1.2.7公司简称:在文件正文内可简称“泰谷生物” 3.1.2.8公司全称:在落款、合同文本等情形必须用全称 3.1.2.9公司文件机密程度说明(详见附件1) 3.1.3请示文格式 3.1.3.1请示标题为三号宋体加粗居中 3.1.3.2正文段落1.5倍行距,字体为四号宋体字 3.1.3.3落款/日期为四号宋体字 3.2公司文件编号要求 3.2.1发文字号编写说明 发文字号简称文号,是由发文机关代字、年份和序号组成。年度、顺序号用阿拉伯数码标识;年份应标全称,序号用中括号“[ ]”括入;序号编虚位(即

公司行政常用公文格式规范及

公司行政公文格式规范及模板 一、文件行文规范: (一)上行文:报告、请示、申请、汇报、总结 1、标题:二号黑体加粗字、居中、无缩进; 2、二级标题: 三号宋体加粗字体,首行缩进两字符; 3、正文: 三号宋体字,首行缩进两字符,行间距为固定值28磅。 4、收尾落款与日脚: 三号宋体加粗字体,居中; 日脚为插入文体字样日期; 通过左缩进至右下脚位置; (二)平行文、下行文;通知、通报、批复、函、意见、纪要、工作联系单。 1、标题: 二号黑体加粗字,居中,无缩进。 2、二级标题: 三号宋体加粗字,首行缩进两字符; 3、正文: 四号宋体字,首行缩进两字符,行间距为固定值25磅; 4、文尾落款和日脚: 四号宋体加粗字、居中,左缩进到右下角。

日脚为插入文体字样日期。 二、行文规定: (一)公文用纸: 1、文本文件:为A4型白纸:210mm×297mm。 2、图纸文件:为A3型白纸:29.7mm×42mm。 (二)装订: 1、文件(红头文件):单面装订; 2、常规文件:单面或双面装订; 3、普通文书:双面装订; 二、公文模板 X矿业股份有限公司文件 新矿司X发[XXXX]XX号签发:XXX XXXXXXXXXXXX XXX: XXXX X股份有限公司 XXXX年XX月XX日主题词:设置组织机构通知 抄报:董事长法人董事会成员 抄送:总经理矿长工程师副矿长矿属各单位 印发:综合管理办公室存:档案室 (一)决定 001.重要事项决定

×××公司关于×××(事由) 的决定 ××××(主送单位): 为了×(目的),根据×(依据),经研究,决定××(决定事项)。 一、×××。 二、×××。 三、×××。 ……(决定的具体内容) (印章) ××年×月×日 002.嘉奖决定 ×××公司关于表彰×××的决定 ××××(主送单位): 最近,×××(被表彰人员或单位的事迹)。×××(被表彰事迹产生的积极影响和表现出的精神)。 为了×××(表彰目的),根据×××(表彰依据),决定对×××等予以表彰(或授予×××等×××称号)。 希望××××(号召向先进学习,提出更高的工作要求和希望)。 附件:表彰名单 (印章) ××××年×月×日 003.处分决定

公司文件格式规范制度

公司文件格式规范 说明 宁夏万盛生物科技有限公司 二0一三年十二月五日

关于公司制度文件格式的说明 ——请各部门根据模板修改相应格式 公司的标准字体为黑体和仿宋_GB2312,公司所有文件执行以下标准: 第一条封皮 凡有封皮的文本,请依据模板设置封皮。 第二条文件标题 公司红文标准格式(发文机关标示)字体为初号,宋体,正文字体为小三号,仿宋_GB2312。其他各种文件中,文件标题均使用黑体、小二号字,加粗;副标题用黑体三号字体,不加粗;标题和正文之间空一行。 第三条正文字体 文件正文字体均为小三号,仿宋_GB2312;标题均使用黑体、小二号字,加粗;副标题用黑体三号字体,不加粗;一级标题为黑体二号字,加粗,二级标题为黑体三号字,加粗;另外,正文前如有填写说明和目录的,请依序安排,其中,填写说明与目录的正文均使用黑体小三号字,不加粗。

第四条行距、段落间距 文件全文行距设置为单倍行距,段落之间和条款之间空一行,各条款中的小标题无须空行。 第五条缩进 段落设置一般为首行缩进(2个字符),含条款的(如合同)为悬挂缩进。 第五条页面设置 页边距上下均为2.50厘米,左右为3.00厘米,页眉距边界为1.5厘米,页脚为1.5厘米。 第六条页眉页脚 对外制度/规范性文件的页眉为靠左加宁夏万盛生物科技有限公司标志,靠右“XXXX管理文件或“XXXX部XX(根据需要分类,如会议等)文件”,一般制度/规范性文件均需要编号,其它只作分类备案用文件无需编号;无论对内对外文件,页脚格式均为“第X页,共X 页”,页眉、页脚均使用黑体小五号字,不加粗。 第七条图表 图表大小可根据需要设定,图表标题需用黑体,三号字体,图

天平通用技术规范

天平 通用技术规范

本规范对应的专用技术规范目录 序号名称编号 1 分析天平专用技术规范1309001-0000-01 2 托盘天平专用技术规范1309001-0000-02 天平物资采购标准 技术规范使用说明 1、本标准技术规范分为通用部分、专用部分。 2、项目单位根据需求选择所需设备的技术规范,技术规范通用部分条款及专用部分固化的参数原则上不能更改。 3、项目单位应按实际要求填写“项目需求部分”。如确实需要改动以下部分,项目单位应填写《项目单位技术差异表》并加盖该网、省公司物资部(招投标管理中心)公章,与辅助说明文件随招标计划一起提交至招标文件审查会: 错误!未找到引用源。改动通用部分条款及专用部分固化的参数; 错误!未找到引用源。项目单位要求值超出标准技术参数值; 错误!未找到引用源。需要修正污秽、温度、海拔等条件。 经标书审查会同意后,对专用部分的修改形成《项目单位技术差异表》(表4),放入专用部分中,随招标文件同时发出并视为有效,否则将视为无差异。 4、技术规范的页面、标题、标准参数值等均为统一格式,不得随意更改。 5、技术规范专用部分由项目单位根据工程情况编写,其中带“××”的文字和技术参数及“项目单位填写”的部分由各项目单位根据工程实际情况和需要必须全面认真填写;空白部分的参数根据需要选择填写;表格中带下划线的技术参数由项目单位和设计院根据工程具体情况更改,不带下划线的技术参数为固化技术参数,技术规范专用部分技术参数表中项目单位与投标人均不需要填写的部分栏目,项目单位应以“—”表示。 6、投标人应逐项响应技术规范专用部分中相应内容。填写投标人响应部分,应严格按技术规范专用部分的“招标人要求值”一栏填写相应的投标人响应部分的表格。投标人填写技术参数和性能要求响应表时,如有偏差除填写“表5投标人技术偏差表”外,必要时应提供相应试验报告。

公司文件格式规范

致力于中国林产工业的技术升级 公司文件格式规范 说明书 永港伟方(北京)科技股份有限公司 二00七年八月八日

永港伟方行政管理文件YG—XZ—070101 关于公司制度文件格式的说明 ——请各部门根据模板修改相应格式公司的标准字体为黑体和楷体,如无特殊说明,公司所有文件执行以下标准: 第一条封皮 凡有封皮的文本,请依据模板设置封皮,并在人事行政部备案。 第二条文件标题 各种文件中,文件标题均使用黑体二号字,加粗;副标题用黑体四号 字体,不加粗;标题和正文之间空一行。 第三条正文字体 各级标题均用阿拉伯数字(1.,1.1,1.1.1)区别。一级标题为黑体 四号字,加粗,二级标题为黑体小四号字,不加粗,三级标题为楷体 _GB2312小四号字,加粗,正文为楷体_GB2312小四号字,不加粗;另 外,正文前如有填写说明和目录的,请依序安排,其中,填写说明与 目录的正文均使用黑体小四号字,不加粗。 第四条行距、段落间距 文件全文行距设置为单倍行距,段落之间和条款之间空一行,各条款 中的小标题无须空行。 第五条缩进 段落设置一般为首行缩进(2个字符),含条款的(如合同)为悬挂缩 进。 第五条页面设置 页边距上下均为2.54厘米,左右为3.17厘米,页眉距边界为1.5厘 米,页脚为1.75厘米。 第六条页眉页脚 对外制度/规范性文件的页眉为靠左“永港(伟方)科技股份有限公司”, 靠右“致力于中国林产工业的技术升级”;对内制度/规范性文件的页

永港伟方(北京)科技股份有限公司致力于中国林产工业的技术升级 眉文字为靠左“永港伟方”,靠右“XXXX管理文件YG—XZ—070101(编 号格式见本规定附录)”或“XXXX部XX(根据需要分类,如会议等)文 件”,一般制度/规范性文件均需要编号,其它只作分类备案用文件无需 编号;无论对内对外文件,页脚格式均为“第X页,共X页”,页眉、页 脚均使用宋体小五号字,不加粗,带格式线。 第七条图表 图表大小可根据需要设定,图表标题需用楷体_GB2312,五号字体,图 表内容中,标题栏需用楷体_GB2312,小四号字体,加粗,加入标准淡 绿色底纹,其它文字内容用楷体_GB2312,五号字体,图表的说明注解 文字则用楷体_GB2312,小五号字体。 第九条落款 文件底部若需要落款,签名和日期请使用黑体小四号字,加粗。 第十条其它固定格式文件 公司其它固定格式文件(公文、信纸、传真、邮件、合同等),请按附 件格式样本(见附件)。 附录部门文件编号格式: 1、行政管理文件YG—XZ—070101、 2、人事管理文件YG—RS—070101、 3、财务管理文件YG—CW—070101、 4、销售管理文件YG—XS—070101、 5、技术研发文件YG—JS—070101、 6、产品市场文件YG—CP—070101、 7、乳液事业部文件YG—RY—070101、 8、木材保护与改性事业部文件YG—MC—070101,依此类推。 永港伟方(北京)科技股份有限公司 2007年8月8日

相关主题
文本预览
相关文档 最新文档