当前位置：文档库 › JTAG协议规范1149.1和1149.7

JTAG协议规范1149.1和1149.7

Doing More with Less – An IEEE 1149.7 Embedded Tutorial : Standard for Reduced-pin and Enhanced-functionality Test Access Port and

Boundary-Scan Architecture

Adam W Ley

ASSET InterTech, Inc. Richardson TX, USA

Abstract

IEEE Std 1149.7 offers a means to reduce chip pins dedicated to test (and debug) access while enhancing the functionality of the Test Access Port (TAP) as a complementary superset of the original IEEE Std 1149.1 (JTAG). Extended features such as hot-plug immunity, power management, optimization of scan throughput, access to instrumentation, and access to custom technologies provide welcome improvements for debug. Further, the boundary-scan architecture is bolstered to ensure full support for test. This important advancement in test and debug interfaces is well suited for access to multiple cores on SOC or multiple die in SIP or POP.

1.Introduction

In the 1980s, the Joint Test Action Group (JTAG) was formed to address a growing concern about diminishing test access to chips on boards due to the adoption of surface-mount assembly methods and ongoing miniaturization of chip packages. In 1990, their efforts culminated in the ratification of IEEE Std 1149.1 – Standard Test Access Port and Boundary-Scan Architecture. While 1149.1 was firmly rooted in the need

to solve the problems of board test, as exemplified by the provision for boundary scan, the proponents of the standard realized the need for a generalized means of low-level access to components on boards and in systems that would suit a wide range of uses. As a result, the 1149.1 test access port (TAP), as specified, has met this need.

In fact, even before the ink was dry, the 1149.1 TAP was being exploited for purposes beyond board test. In these early days, its utility was deployed to support access to chips for in-circuit emulation (debug), albeit often with additional pins for proprietary signals. Somewhat later, the ubiquity of the 1149.1 TAP was exploited in a normative sense for in-system configuration of programmable devices by way of IEEE Std 1532. Later still, use of the 1149.1 TAP as a debug interface was standardized by NEXUS 5001 (although still requiring additional signaling for many cases). Today, for the same reasons of utility and ubiquity, the 1149.1 TAP is considered the most likely means of access to chips that support embedded instruments per P1687 (informally known as Internal JTAG or IJTAG).

Notwithstanding the exceptional merits of the 1149.1 TAP, ongoing industry momentum toward greater miniaturization and still more integration led some to the conclusion that a makeover was needed [1]. In particular, they proposed to enhance its functionality and utility in applications debug, but also to reduce pins to be better suited to multi-core/ multi-die architectures. IEEE Std 1149.7 [2, 3, 4, 5] has been developed to meet these needs [6, 7, 8, 9, 10, 11, 12].

1.1What is IEEE 1149.7

IEEE 1149.7 is a standard for a test access port and associated architecture that offers reduced pins and enhanced functionality. With regard to pin reduction, whereas the conventional 1149.1 TAP (TAP.1) requires at least four signals (with a fifth, for test reset, being optional), the reduced-pin 1149.7 TAP (TAP.7) requires only two signals (with the possibility for encoding the optional test reset function onto these). Further, with regard to functionality enhancement, it is expected that, in many cases, extended signaling needs for uses such as applications debug can be met on no more than two pins. Even while delivering these benefits, 1149.7 has taken great pains to preserve the investment that the industry has made in 1149.1 for chips and on boards. Particularly, 1149.7 adopts the entirety of the 1149.1 boundary-scan architecture to fully support board test and in-system configuration. Further, 1149.7 does not replace 1149.1, but rather adapts it and extends it, building upon its foundation and legacy. For example, as illustrated in Figure 1, an 1149.1 chip can be adapted easily to provide a TAP.7. As well, TAP.7s can coexist with TAP.1s on boards and, in some cases, even on the same board-level TAP connections.

“before”“after”

Figure 1—Adaptation of 1149.1 to 1149.7

1.2

IEEE 1149.7 Key Objectives

The key objectives for 1149.7 fall broadly into three categories – system architecture, applications debug, and legacy infrastructure (to include test).

Benefits for system architecture derive from the appropriate accommodation of multiple on-chip embedded TAP Controllers (EMTAPC), the reduction of pins, the adoption of glue-less star topology, independence from CPU/debug technology, and provisions for power management. Where intellectual property (IP) blocks may each contain EMTAPCs, multiples of these may be accommodated on a complex system-on-chip (SOC). While reduced pin count has inherent value with respect to miniaturization, consider as well that, in combination with the star topology, fewer pins better support the new 3D packaging methodologies such as system-in-package (SIP). These typically involve the stacking of die as shown in Figure 2; conversely, a daisy-chaining implementation is not only more difficult but also is not 1149.1 compliant. Of course, the same can be said for package-on-package (POP). Further, independence from particular CPU/debug technologies supports similar integrations even where chips may incorporate CPU IP from multiple sources. Facilities that permit the test logic to enter power-down modes support increasingly aggressive power management requirements.

Figure 2—Star topology for a 3-die SIP

For applications debug, the TAP.7 provides advanced capability that reduces or eliminates the need for signaling beyond the two wires. Extensions provided include robust hot connect, increased throughput by way of scan optimization, higher operating frequency, and transport of background instrumentation data and/ or custom protocols. Of course, independence from CPU/debug technology also accrues here because uniform tool sets can support chips with heterogeneous CPUs.

Finally, as concerns the legacy infrastructure, the objectives are two-fold – first, honor 1149.1 by preserving the test infrastructure that has been built up around it and on which the industry depends; and second, maintain a level of compliance such that existing intellectual property in chips, on boards, and in debug and test systems (DTS) can be adapted at low cost.

2. Overview/ How it Works

At the highest level of abstraction, 1149.7 provides for a chip-level TAP.7 Controller that bridges the conventional 1149.1-accessible System Test Logic (STL) to the four (five) or two (three) wires of the chip-level TAP.7 (the test reset signal is optional in either case). The STL has its own 1149.1 chip-level TAP Controller (CLTAPC) and all of the associated test logic architecture, including a chip-level boundary-scan register and related EXTEST, PRELOAD, and SAMPLE instructions.

Seeking to extend 1149.1 in a compatible fashion, 1149.7 starts with the observation that the TAP Controller (TAPC) at the core of 1149.1 is a two-wire control means, even in the conventional series topology, as shown in Figure 3.

TCK TDI

TDO

TMS

Figure 3—Conventional series topology, highlighting the star

wiring for TCK/TMS

Per 1149.1 convention, the starred TCK/TMS can only advance the TAPC state, which in turn invokes TDI/TDO for scan operations, but, absent instruction register scans, does not change the mode of the test logic. Thus, the key concept of 1149.7 continues with the observation that control extensions might be overlaid on sequences of TAPC states (more details on this later).

Thus, 1149.7 adds its own commands and registers on which the other layers of extended functionality are based. These additional layers add scan formats, direct addressability, packetization of scan data (TMS, TDI, and/ or TDO information) onto the TMS wire (hence, re-designated TMSC), and finally packetization of non-scan information onto TMSC to provide for transport of background and/ or custom data.

As such, 1149.7 supports a number of capability classes (six in number, designated as T0 - T5). So the TAP.7 Controller is configurable to support the required capability for a given implementation. The primary functional units are illustrated in Figure 4 and are designated as follows: Advanced Protocol Unit (APU), Extended Protocol Unit (EPU), Pin-Sharing Logic (PSL), and Reset and Selection Unit (RSU). The manner in which these items are invoked (or not) for given capability classes will be described in subsequent sections.

TDI(C)nTRST EPU TAP.7TDO(C)

TCK(C)TMS(C)TAP.7 Controller

Figure 4—Notional view of the 1149.7 architecture

2.1 Capability classes

Regardless of which capability class is implemented, a given TAP.7 must implement all of the mandatory features of its own class as well as those of all lower-numbered classes (T0 < T5). The classes are generally considered in two primary groupings: those which extend 4-wire operation (T0 – T3) and those which provide the reduced-pin, 2-wire operation (T4 – T5).

T0–foundation

As the foundation of all TAP.7 capabilities, T0 begins with 1149.1-Specified behavior, such that the T0 STL is 100 percent compliant to 1149.1 including provisions for the mandatory chip-level boundary-scan architecture. With 1149.7 T0, the chip-level device identification register becomes mandatory.

Of the TAP.7 Controller elements shown in Figure 4, only the RSU is permitted as an option; the other items are reserved for higher classes.

Where the RSU is implemented, this would be done, as for any other class, to permit Escape Sequences and/ or Selection/Deselection Alerts to be available to manage the sharing of TAP.7 signaling across technologies and topologies. When the TAP.7 Adapter TAPC (ADTAPC) is deselected, the CLTAPC will be parked. These topics will be addressed in greater detail with T3 where the RSU becomes mandatory.

Of particular note, even where the chip has multiple EMTAPCs, as might be the case for a complex SOC that implements a mix of several core IP blocks, the T0 STL shall provide 1149.1-Specified behavior from the Test-Logic-Reset TAPC state. 1149.7 identifies several means by which EMTAPCs can be selected under the control of the CLTAPC. A further method is defined for managing multiple die-level TAPCs in a similar manner for SIP. T1–commands and registers

With T1, the 1149.7 mechanism providing extended control by way of TCK/TMS is invoked to access 1149.7 commands and registers. These functions pertain to the EPU as illustrated in Figure 4. So, the EPU block of the TAP.7 Controller is present for T1. Otherwise, excepting the RSU, as for T0, all other blocks are reserved for higher classes.

As described earlier, the extended control mechanism operates without disruption to the conventional 1149.1 TAPC state machine. Rather, it uses a particular state sequence, which is benign to normal 1149.1 operations, to initiate 1149.7-defined action.

The state sequence of interest is known as a zero-bit DR scan (ZBS) and these are to be operated only while all of the CLTAPCs in the selected topology operate BYPASS or IDCODE so as to ensure that they do not disrupt normal system operation. In fact, ZBS detection is validated only when no IR scans have intervened since the last occurrence of the Test-Logic-Reset TAPC state.

The progression of states that is recognized as a ZBS is illustrated in Figure 5.

Scan

Capture-DR

Exit1-DR

Exit2-DR

Update-DR

Shift-DR

Pause-DR

Figure 5—Zero-bit scan (ZBS)

There are actually two different paths, labeled as “a” and “b” in Figure 5, that can implement a ZBS. In either case, the state sequence of interest is defined as follows: from the Select-DR-Scan TAPC state, proceed to the Update-DR TAPC state without passing the Shift-DR TAPC state. From the Test-Logic-Reset TAPC state, wherein the ZBS count is set to zero, the extended control mechanism is initiated when at least two ZBSs are detected before a subsequent non-zero-bit DR scan, which locks the ZBS count. A locked ZBS count of two provides access to the 1149.7 commands and registers. Locked ZBS counts greater than two access higher control levels that will not be detailed here.

Once the ZBS count is locked, and a control level set, it is only unlocked when the control level is exited by entry to either the Select-IR-Scan or Test-Logic-Reset TAPC states or by certain 1149.7 commands and events that are used to synchronize T4 and T5 operations.

At control level 2, commands are recognized, without the use of TDI/TDO pins, by counting the number of TCK(C)

ticks in the Shift-DR TAPC state for two scans that immediately follow the completion of the non-zero-bit DR scan that locked the ZBS count. Each of these two primary command words is coded in 5 bits, ensuring that these counts need not exceed 31. All commands include two such parts for a total code length of 10 bits. In most cases, the command and register operations are concluded in these two parts but in some (only three) special cases a third part (a DR scan of a length determined by the control register addressed by the command) is required.

T1 mandates a given minimum set of such commands and the registers that they address. Additionally, some commands, registers, and associated functions are optional, notably those that invoke directed test reset generation and request for functional reset.

Additionally, T1 provides for power management through four modes of power control for the test logic. These four modes are: allow power down if TCK stops at logic one for more than 1 ms, allow power down if TCK stops at logic one for more than 1 ms in the Test-Logic-Reset TAPC state, allow power down if the device is in the Test-Logic-Reset TAPC state, and do not allow power down (the test logic is always powered).

Given that a power-down mode is supported, the test logic is directed to resume powered operation when the Run-Test/Idle TAPC state is forced for at least 100 ms and at least 3 TCK(C) ticks.

T2–scan formats

The 1149.7 scan formats are introduced in T2. A T2 TAP.7 supports JScan0 – JScan2; other scan formats are reserved for higher classes.

Of the TAP.7 Controller elements shown in Figure 4, for T2, as for T1, only the EPU is mandatory with the RSU permitted as an option; the other items are reserved for higher classes. For T2 versus T1, the EPU adds the commands and registers associated with the scan formats. As regards the function of these scan formats, JScan0 provides 1149.1-Specified behavior while JScan1 provides for the deselection of the CLTAPC in favor of a 1-bit scan path (so-called Super Bypass) that is active for IR scans as well as DR scans and JScan2 provides for activation/deactivation of the Super Bypass according to the value of an 1149.7 register.

A T2 TAP.7 can opt either for JScan0 or JScan1 as its startup behavior. The latter case is described as providing hot-plug immunity since it should permit live connection (or disconnection) of the TAP.7 signals to be non-disruptive to the test logic.

T3–direct addressability

Finally, with T3, the star topology (4 wire), as in Figure 6, is supported. This comes by adding the means for direct addressability and the JScan3 scan format that provides for scans to star-4 topologies.

Figure 6—Star-4 topology

Of the TAP.7 Controller elements shown in Figure 4, T3 adds the RSU as a mandatory element in addition to the EPU. For T3 versus T2, the EPU adds the commands and registers associated with direct addressability. Note that for T3, the TDI and TDO signals are re-designated as TDIC and TDOC, respectively.

Concerning the RSU for T3, it is required to implement Escape Sequences for reset and for selection/ deselection and may optionally implement Selection and Deselection Alerts. Escape Sequences involve the detection and counting of a number of edges on TMS(C) driven while TCK(C) is held at logic 1. The count of such edges determines the action to be taken in response to the Escape Sequence. Alerts are specific predefined sequences of 128 bits as driven on TMS(C).

The resource invoked for support of direct addressability is the TAP.7 Controller Address (TCA), as shown in Figure 7. The values corresponding to DEVICE_ID are inherited from the 1149.1 device identification register capture value for the CLTAPC. The assignment of the NODE_ID is made by some implementation-specific means that is not defined by 1149.7. The NODE_ID serves to distinguish multiple TAP.7s on a given topology branch where they are of the same device type.

Figure 7—TAP.7 Controller Address (TCA)

A key provision required to facilitate scans to the star-4 topology is the prevention of drive conflict on TDOC. The JScan3 format is managed so that when multiple TAP.7 Controllers are requested to participate, then drive on TDOC will be inhibited.

As discussed in more detail in 4.1, test applications require the ability to coordinate the simultaneous entry of all devices of interest into and/ or through the Capture-xR, Update-xR, and Run-Test/Idle TAPC states. At first glance, the star topology would seem not to support this requirement. But in addition to the JScan3 scan format, T3 adds the Scan Selection Directives (SSD) to deal with this matter. The SSDs make use of Pause-xR TAPC states as parking states to which simultaneous scan captures are

directed and from which simultaneous scan updates are directed. Scan shift operations, as necessitated by the star topology are done on a device-by-device basis and are both directed from and to the Pause-xR TAPC states. T4–packetization of scan data (2-pin scan formats)

With T4, a number of additional scan formats are added to support the advanced protocol, which is operated on two pins. The TCK/TMS pins are re-designated as TCKC/TMSC, respectively. The corresponding star-2 topology is illustrated in Figure 8. Note that TMSC is bidirectional.

TMSC

TCKC

Figure 8—Star-2 topology

Of course, these additions require the provision of the APU of Figure 4. As well, since the TDIC/TDOC pins are optional since they are not used for 2-pin operation, where they are provided the PSL also becomes an option. Where a T4 TAP.7 does not provide the TDIC/TDOC pins in any configuration, it is described as narrow and designated as T4N. Where a T4 TAP.7 does have a configuration that provides the TDIC/TDOC pins, it is described as wide and designated as T4W.

One of the more basic scan formats that supports the advanced protocol is OScan1. The serialization of the scan packet for OScan1 is illustrated in Figure 9. As shown, the TDI bit information is inverted. Also, for each cycle in which the TDO bit appears it is driven from the selected device in the target system back to the DTS.

TCKC TMSC state

Figure 9—Scan packet serialization – OScan1

Other scan formats in the OScan series provide for optimizations in which the scan packets omit bits that can be known to carry no significant information. An example worth noting is the OScan7 format which is optimized for downloads from the DTS to the target system. For OScan7, as illustrated in Figure 10, only the TDI bit information is included in the packets sent during Shift-xR TAPC states.

TCKC nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDI

TMSC Shift-xR

Shift-xR

state

Figure 10—Scan packet serialization – OScan7

Further performance optimization that can be obtained for T4 is by invoking falling-edge sampling for TMSC which, presuming hold times still can be met, delivers a degree of improvement in setup times that would allow the TCKC frequency to be increased (perhaps doubled).

T5–transport of non-scan data (2-pin mode)

At the top of the classes, T5 offers the capability to interleave transfers of non-scan data among the scan transfers. This is referred to as transport and has two variants – background data transport (BDX) and custom data transport (CDX).

Both types of transport can use any combination of Run-Test/Idle, Pause-xR, and Update-xR TAPC states after which to insert transport packets. The distinction is that, whereas BDX has fixed allocation of I/O bandwidth available to the chip-level data channel, CDX has a custom allocation of I/O bandwidth as determined/ defined by the chip-level unit.

2.2 Selection hierarchy

While some aspects of the selection hierarchy have been described above, some additional detail is warranted as it is a key aspect of the 1149.7 system architecture.

In general, where selection is enabled within the hierarchy, those items not selected are effectively offline/ parked and respond only to particular selection requests on the TAP.7 signaling. Those that are selected are online and respond to the TAP.7 signaling according to the protocols for which they are configured.

Five levels in the selection hierarchy are elaborated below. For each level of the hierarchy, one or more selection mechanisms may pertain. - Technology

Where the 1149.7 technology can be placed offline, the TAP.7 signaling can be shared with other technologies

- Topology

W here the constituent 1149.7 devices can be placed offline (a function required for T3 and above), the TAP.7 signaling can be shared among any topology branches, whether series, star-2, or star-4 - Adapter (i.e., ADTAPC)

1149.7 devices comprising a selected topology branch will share TAP.7 signaling and, where the topology branch is star-2 or star-4, a given device may be selected for a given operation

- Chip (i.e., CLTAPC)

For a selected ADTAPC, the CLTAPC may be offline and will require selection when it must be operated

- Core (i.e., EMTAPC)

For a selected CLTAPC, given EMTAPC(s) of interest may be offline and will require selection when it (they) must be operated

3.Implications for Debug

In many respects, 1149.7 was defined by and for the debug community. Thus, many of the implications, considerations, and supporting features have already been addressed in the elaboration of the basic 1149.7 functions as described above. Still some of these bear specific mention in this context.

3.1Debug considerations

Chief among the considerations for debug are ease and efficiency. Of course, these unfold across multiple dimensions and are often intertwined.

Ease

The highest degree of visibility and control is required to drive the analysis tools that can get to the bottom of thorny problems that arise in today’s multi-threaded, multi-core, real-time embedded systems. 1149.7 promises to bring value to this equation by consolidating debug access for multiple cores onto a smaller number of chip pins.

Other features tending toward ease of debug are the hot-plug immunity and system interrogation.

Efficiency

Certainly 1149.7 enjoys a performance boost relative to 1149.1 with its various optimizations for scan throughput and its ability to improve link utilization by using otherwise idle non-scan states to transport background instrumentation data.

3.2Debug features

As one would expect, 1149.7 brings a wealth of features to address debug ease and efficiency.

Access consolidation

Several aspects of the 1149.7 system architecture provide for access consolidation: management of EMTAPCs (T0), star topology (T3), pin reduction (T4N/T5N), and capability for the TAP.7 to transport background data and custom protocols (T5). All of these result in making debug instrumentation more accessible and, hence, easier to use. Hot-plug immunity

Live connection without system disruption is vital and is enabled by the offline at startup (T3 or any with RSU) and Super Bypass at startup (T2) features. System interrogation

A method for topology interrogation (T3) is provided and enumeration of controllers can be made by undirected allocation of Controller IDs (CID) (T3), as in Figure 11. These features allow the system architecture to be discovered by the debug tool at connect time.

Each participating chip drives its AT[n]

on wired-OR basis (logic 1 inactive)

All supporting chips without CID participate;

chips with a CID do not participate.

For each participating chip, its aliasing target

AT[35:0] = TCA[34:0] + 0

Final n?

Each chip that detects that its

AT[n] != TDO drops out

Next n

The chip that matched all 36 bits

of its AT to all 36 bits of TDO

wins and gets the CID

Figure 11—CID Allocation, Undirected Optimization of scan throughput

Perhaps above all, 1149.7 offers a great number of opportunities to optimize scan throughput. Super Bypass (T2) results in shorter scan chains for series topology. Star topology (T3) offers direct addressability and, hence, scan operation in only the target of interest.

Advanced protocol (T4) offers still further improvements based on scan packet optimization on one hand and falling-edge timing (and thereby clock doubling) on the other.

Improved link utilization

BDX and CDX (T5) allow the link to be used for transport of instrumentation data even during non-scan states, which would otherwise be idle.

4.Implications for Test

While 1149.7 primarily has been developed for the benefit of applications debug, it also has gone to considerable lengths to ensure that the test legacy of the original 1149.1 is honored. Among the several test-related provisions are the scan selection directives that ensure update/ capture/ run-test synchronization and the definition of suitable test languages.

4.1Test considerations

While 1149.7 does not change radically how 1149.1 boundary scan/ test is being used today, there are some new considerations for test that arise with the 1149.7 architecture. Primary among these are the divergence in

scan-state sequencing and series/star interoperability. Other considerations worth mention are hierarchical navigation, power control, and large-system applications. Scan-state sequencing

The typical test application has requirements for scan-state sequencing that necessitate coordination of application of stimuli across multiple distinct components (with their own boundary-scan registers) on a given unit under test (UUT). Consider the case where several components have distinct 3-state outputs on a shared wire junction. If the distinct output control cells in each of these components were not updated in a coordinated fashion, a contention could be present on the shared wire. The simplest means of such coordination is to ensure that all components pass simultaneously through the Update-DR TAPC state.

As well, while it might not be necessary in some cases, the coordination of the acquisition of response generally also is required (or at least preferred). At the least, where specific response to given stimuli is required, the distinct responses for each component involved must all be acquired before the applied stimulus is changed. Here again, the simplest means for such is to ensure that all components pass simultaneously through the Capture-DR TAPC state (in fact, simultaneity may be strictly required in some special cases).

Some test applications, such as the testing of advanced digital networks per IEEE Std 1149.6, have an additional requirement that all components participating in such testing must pass simultaneously through the Run-Test/Idle TAPC state.

Conventional scan sequencing for test applications presuming series topology is illustrated in Figure 12.

Run-Test-Idle 1Select-DR-

Scan

Capture-DR

Exit1-DR

Exit2-DR

Update-DR

Shift-DR

Pause-DR

Figure 12—Scan-state sequence (conventional) for test

applications, series topology This conventional scan-state sequence can be broken down as follows:

- (in yellow) all components on the UUT (series topology) pass through the Capture-DR TAPC state wherein responses (to a previously applied stimulus) are acquired in concert

- (in red) all components on the UUT (series topology) enter and remain in the Shift-DR TAPC state until all responses have been exported and all new stimuli have been imported

- (in blue) all components on the UUT (series topology) pass through the Update-DR TAPC state wherein new stimuli are applied in concert

- (in grey) all components on the UUT (series topology) dwell in/ pass through the Run-Test/Idle TAPC state wherein transient stimuli may be generated in concert The divergence introduced by the 1149.7 star topology is that, due to shared wiring of TDIC and TDOC for star-4 or TMSC for star-2, only one component may be operated in the Shift-DR TAPC state at a time.

Fortunately, we can take from the above discussion that the Shift-DR TAPC state is actually neutral to the requirements of the test application. Thus, the needs of the test application can be served, even for a star topology if each of the TAPC states Capture-DR, Update-DR, and Run-Test/Idle can be operated in concert across all of the UUT components of interest.

It is for just this purpose that the scan selection directives (SSD) were devised. Figure 13 illustrates the scan-state sequence made possible by the SSDs (star topology).

Figure 13—Scan-state sequence for test applications,

modified for star topology

This modified scan-state sequence can be broken down as follows:

- (in yellow) all components on the UUT (star topology) pass through the Capture-DR TAPC state, wherein responses (to a previously applied stimulus) are acquired in concert, and then on to Pause-DR

- (in red) each component on the UUT (star topology) is brought, one at a time, from Pause-DR to enter and remain in the Shift-DR TAPC state until its responses have been exported and its new stimuli have been imported, and then back to Pause-DR; this step is repeated once for each component of interest to the test application

- (in blue) all components on the UUT (star topology) pass through the Update-DR TAPC state, wherein new stimuli are applied in concert, and then on to Run-Test/Idle TAPC state

- (in grey) all components on the UUT (star topology) dwell in/ pass through the Run-Test/Idle TAPC state, wherein transient stimuli may be generated in concert The use of this same sequence can be extended beyond just one star topology to include several distinct star topologies (such as with separate TCK) and even further to accommodate a mix of series topologies with star topologies on the same UUT.

Hierarchical navigation

Another consideration for test involves the divergence that results from the introduction of selection hierarchy throughout 1149.7-based systems. These layers are technology, topology, adapter, chip, and core, as detailed in 2.2. A test application must navigate these layers using their respective selection mechanisms to access the desired TAPCs wherever they may reside in the hierarchy.

Power control

A further consideration for test arises concerning control of the power-down modes to avoid inadvertent loss of power to components required to support the test application. W hen one or more of the components of interest implement a power-down mode, this DTS must issue a directed power-up request to bring it (them) out of Test-Logic-Reset TAPC state. This involves forcing TMS(C) to 0 for at least 100 ms followed by at least 3 TCK(C) ticks in the Run-Test/Idle TAPC state. Considerations for large-system applications

Whereas debug typically involves a small-system view (even where the system of interest may be part of a much larger system), test applications often involve large systems. These may comprise large printed circuit boards (PCB) and/or collections of many such PCBs.

Some aspects where large-system applications (such as for test) contrast versus small-system applications (such as for debug) include: the numbers of components (great versus few), the dispersion of components (spread across many substrates, e.g. PCBs, versus on a single substrate), the available real estate for access to TAP signals (plenty versus limited), and the logical and electrical constraints on connectivity (many devices/ loads versus few).

As a result, for some large-system applications, the star-2 topology may not provide adequate connectivity. Furthermore, an abundance of real estate may render the reduced-pin TAP.7 unnecessary. Where such factors can be known in advance, system architects may wish to consider them in regards to the specification of supported topologies.

4.2Test languages

Recognizing that a set of description files is required to support test applications, 1149.1 introduced the Boundary-Scan Description Language (BSDL), hereafter referred to as BSDL.1. Likewise, 1149.7 recognizes the need for additional description elements and so has offered its own BSDL derivatives.

Consider the example 1149.7 component illustrated in Figure 14. The items identified as “Chip A” and “Chip B” are further identified as test endpoints, signifying that they each contain a single CLTAPC that exposes a single boundary-scan register for external test. The embracing item is identified as a test module because it must necessarily contain more than one CLTAPC and must expose more than one boundary-scan register for external test.

Figure 14—Example 1149.7 component comprising a test

module with two test endpoints

Note that according to the above classification criteria, a test endpoint could be one that provides 1149.1-Specified behavior just as well as one that provides 1149.7-Specified behavior. Thus, as a corollary to the BSDL.1, 1149.7 has specified a BSDL variant (BSDL.7) for test endpoints.

In contrast to 1149.1, 1149.7 has expressly considered hierarchy within its bounds. Consider that an item classified as a test module per the above criteria can be one that provides 1149.7-Specified behavior. In fact, in the general case, a test module is defined as a collection of test endpoints and other test modules where TAPs are connected to define a scan topology.

Since test modules can contain other test modules as subcomponents, a hierarchy is formed. While the simplest

test module contains one or more devices connected into a single scan topology, more complicated test modules can represent multi-chip modules, etc. Thus, the need for a new, hierarchical description has been recognized and the 1149.7 Hierarchical Scan Description Language (HSDL.7), based on BSDL.7, has been defined.

With the combination of BSDL.7 and HSDL.7 descriptions as identified above, and a top-level netlist for the given UUT, test software can extract scan chain topology and other connection information needed for test generation. The inclusion of component-to-component functional connections in the HSDL.7 provides for the testing of intra-module connections where possible. Describing 1149.7 test endpoints–BSDL.7

As for BSDL.1, the BSDL.7 model of a component (test endpoint) is effectively an electronic data sheet for parameters of the test logic that may vary from one component to another. As 1149.7 has added some new parameters that may vary from chip to chip, these need to be accommodated in the BSDL.7. Otherwise BSDL.7 derives entirely from the BSDL.1.

Figure 15 presents the attributes that are new for BSDL.7 (versus BSDL.1).

attribute COMPONENT_CONFORMANCE_ADAPTER attribute COMPONENT_CONFORMANCE_STL attribute TAP_CLASS

attribute TAP_SCAN_CLOCK_COMPACT attribute TAP_SCAN_MODE_COMPACT attribute TAP_SCAN_IN_COMPACT attribute TAP_SCAN_OUT_COMPACT attribute TAP_SCAN_RESET_PD attribute CNFG0_REGISTER attribute CNFG1_REGISTER attribute CNFG2_REGISTER attribute CNFG3_REGISTER

Figure 15—Attributes added for BSDL.7

Taken together, the BSDL.7 attributes COMPONENT_CONFORMANCE_ADAPTER and

COMPONENT_CONFORMANCE_STL replace the BSDL.1 attribute COMPONENT_CONFORMANCE and,

respectively, indicate the conformance level of the TAP.7

(which is governed by 1149.7) and of the system test logic (which is governed by 1149.1). As a group, BSDL.7’s new TAP_CLASS and TAP_SCAN attributes augment the existing BSDL.1 TAP_SCAN attribute. As appropriate for the supported class, these complete the description of the TAP.7 (scan port) to comprehend its possible extensions relative to the TAP.1, whether narrow or wide, falling edge timing, etc.

The BSDL.7 attributes that begin with CNFG are completely new. These allow the content of the 1149.7 configuration register to be expressed. The bit values

contained within the BSDL.7 can be mapped out to determine all of the chip-specific capability options. Describing 1149.7 test modules–HSDL.7

An HSDL.7 model of a component (test module) likewise is effectively an electronic data sheet for the parameters of the test logic that may vary from one component to another. Of course, the parameters that are of interest to HSDL.7 are those that pertain to test modules, versus those that pertain to test endpoints for BSDL.7 (which are omitted as appropriate).

Figure 16 presents the attributes that are new for HSDL.7 (versus BSDL.7).

attribute COMPONENT_CONFORMANCE_MODULE attribute MEMBERS

attribute MEMBERS_PORTMAP attribute MEMBERS_NODEIDS

Figure 16—Attributes added for HSDL.7

Attribute COMPONENT_CONFORMANCE_MODULE of HSDL.7 replaces those for BSDL.7 with prefix COMPONENT_CONFORMANCE_ and correspondingly indicates the conformance level of the test module (as opposed to the TAP.7(s) and/ or STL(s) of its constituent subcomponents).

As a group, the HSDL.7 attributes that begin with MEMBERS are completely new. These list the subcomponents of the test module, describe how these subcomponents are interconnected, and assign NODE_IDs to the subcomponents, as needed. When combined with the DEVICE_ID information from the associated BSDL.7 file(s), the full TCA(s) of the test endpoints can be determined.

5. Conclusion

IEEE 1149.7 ratifies a test and debug interface that is a complementary superset of the venerable IEEE 1149.1

(JTAG) TAP. By way of options for reduced pins and for

enhanced functionality, 1149.7 offers an access mechanism that is well suited to interfacing multiple cores

on SOC or to interfacing multiple die in SIP or multiple packages for POP. While the enhanced functionality is necessary to support the reduced-pin access capability of 1149.7, it also provides a number of features that improve the debug process. Such features include hot-plug immunity, power management, optimization of scan throughput, access to debug instrumentation, and access to custom debug technologies.

Still, the enhanced functionality and the reduced pin capability are deployed in such a way as to maintain compatibility for test. It will be possible for chips that have IEEE 1149.7 TAPs to reside on modules and boards with chips that have IEEE 1149.1 TAPs and, further, for

the test logic in these chips to interoperate to perform a test application (e.g., boundary scan) that spans these chips.

Finally, it is expected that, even though 1149.7 is, indeed, a new standard, it will have a leg up with regards to adoption by industry due to its having been laid solidly on the foundation of 1149.1. In effect, 1149.7 already has a presence in the marketplace thanks to its ancestor, 1149.1. In fact, the significant infrastructure already in place for 1149.1 will be leveraged to bring 1149.7 solutions to market in short order.

6.Acknowledgements

The author acknowledges all those involved in the P1149.7 working group, without whose effort a standard would not have been realized. A further recognition goes to Stephen Lau of Texas Instruments, upon whose training and education materials this embedded tutorial/ paper has drawn. Finally, and most especially, the author thanks Gary Swoboda of Texas Instruments, who shall be recognized as the technical architect and principal author of 1149.7.

7.Disclaimer

Where discrepancies between the descriptions presented herein may arise with respect to the ratified IEEE Std 1149.7, the latter shall be considered authoritative. If any such errors are present, they should be considered the sole responsibility of this author. 8.References

[1]“MIPI Test and Debug Interface Framework White

Paper”, MIPI Alliance, 2006,

https://www.wendangku.net/doc/bf5825074.html,/docs/MIPI_TDWG_whitepaper_v3_2.

pdf

[2]“IEEE P1149.7 Project Authorization Request

Approval Letter”, IEEE SA Standards Board, 2006,

https://www.wendangku.net/doc/bf5825074.html,/board/nes/projects/1149-7.pdf

[3]“IEEE P1149.7?/D1.22 Draft Standard for Reduced-

pin and Enhanced-functionality Test Access Port and

Boundary-Scan Architecture”, IEEE, 2009

[4]“IEEE Standard 1149.7 (web site)”, IEEE-SA, 2009,

https://www.wendangku.net/doc/bf5825074.html,/groups/1149/7/

[5]“IEEE 1149.7 - Texas Instruments Embedded

Processors Wiki”, Texas Instruments, 2009,

https://www.wendangku.net/doc/bf5825074.html,/wiki/index.php?title=IEEE_1149.7

[6]R. Goering, “'Compact JTAG' standard targets on-chip

debug,” SCDsource, 2008, https://www.wendangku.net/doc/bf5825074.html,/article.php?id=310

[7]S. Lau, “Reinventing JTAG for SoC debugging,”

Embedded Systems Design, 2008,

https://www.wendangku.net/doc/bf5825074.html,/design/210200584

[8]S. Lau, “IEEE 1149.7: Expanding and improving

JTAG,” Embedded Computing Design, 2008,

https://www.wendangku.net/doc/bf5825074.html,/articles/id/?3687

[9]S. Lau, “IEEE 1149.7 Expands JTAG Functionality”,

Evaluation Engineering, 2009, https://www.wendangku.net/doc/bf5825074.html,/features/2009_

july/0709_design.aspx

[10]N. Stollon, “Embedded Instrumentation Integration

Using IEEE Nexus 5001 and 1149.7”, Design And

Reuse, 2009, http://www.design-

https://www.wendangku.net/doc/bf5825074.html,/articles/21304/ieee-nexus-5001-1149-

7.html

[11]A. W. Ley, “Nascent 1149.7 complements venerable

1149.1 JTAG,” IPextreme, 2008, http://www.ip-

https://www.wendangku.net/doc/bf5825074.html,/newsletter/newslet_081215/newslet_081215.ht

ml#techtip

[12]A. W. Ley, “New 1149.7 enhances 1149.1 test access

port, maintains compatibility for boundary scan,”

ASSET InterTech, 2009, http://www.asset-

https://www.wendangku.net/doc/bf5825074.html,/connect/2009Q1/1149dot7.htm

进一步规范公司合同协议书管理工作的通知

进一步规范公司合同协议书管理工作的通知文件排版存档编号：[UYTR-OUPT28-KBNTL98-UYNN208]

关于进一步规范公司合同管理工作的通知公司各部门：为进一步规范合同管理工作，避免和减少因合同管理不当造成的不必要损失。根据国家相关法律、法规，结合本公司实际，经公司研究决定对合同管理的有关事项通知如下：一、根据《中华人民共和国合同法》相关规定，本通知所称“合同”不仅包括以书面形式订立的合同，还包括与他人（含法人、其他组织、自然人）发生的存在经济权利义务关系的所有行为。二、公司所签订合同必须主体合格，标的合法，手续完备，条款齐全，意思表达真实，约定明确，文字清晰，语言规范，无矛盾条款，无空白条款。三、凡单笔业务金额达二十万元（含）以上或有抵押担保的合同须经办人填写合同审批表，由部门负责人审核、签字，经公司行政办及财务部审核无异议后，报请法定代表人批准，方可加盖合同专用章。单笔业务金额在二十万元以下且无抵押担保的合同，由公司行政办及财务部对合同条款进行审核，无异议后方可加盖合同专用章。四、公司行政办是合同管理的归口部门，印鉴管理工作实行专人负责制，若出现印鉴管理人员不在岗的情况，则任何人不得私自取用印鉴，特殊情况须报请公司法定代表人批准。

五、如需借用公司合同专用章外出，经办人员须获取公司法定代表人签定的《用章申请表》和书面授权书，并将拟签订的合同交由公司行政办复印留底后方可办理借用登记手续，委托代理人在签订合同时，不得超越委托书的权限范围。如在合同签订过程中出现合同条款需要改动的情况，则须将改动后的合同相关材料先传真回公司，经公司法定代表人评审同意后，方可签字盖章。六、合同签订后，经办人员上交合同如与已审核文本相符，相应审核资料按规定归档；如上交合同与已审核文本不符，则按公司规定严格追究相关人员责任。七、在合同履行过程中，合同对方所开具的发票须先由经办人员审核签字认可，交由财务部审核，并报法定代表人签字同意后方可付款。八、变更或解除合同须依照合同的订立流程经业务部门、财务部门、行政办等相关职能部门和公司法定代表人审核通过方可办理。我方变更或解除合同的通知或双方的协议应当采用书面形式，并按规定经审核后加盖公章或合同专用章，合同变更后，合同编号不予改变。九、公司严格执行谁签订的合同，谁负责追踪合同履行情况并将追踪结果及时上报公司领导。十、单份合同文本达二页以上的须加盖骑缝章。

合同管理制度范本

公司合同管理制度第一节总则第一条为加强经济合同管理，减少失误，提高经济效益，根据《经济合同法》及其他有关法规的规定，结合公司的实际情况，制订本制度。第二条公司各部门及下属公司、企业对外签订的各类经济合同一律适用本制度。第三条经济合同管理是企业管理的一项重要内容，搞好经济合同管理，对于公司经济活动的开展和经济利益的取得，都有积极的意义。各级领导干部、法人委托人以及其他有关人员，都必须严格遵守、切实执行本制度。各有关部门必须互相配合，共同努力，搞好公司以“重合同、守信誉”为核心的经济合同管理工作。第二节经济合同的签订第四条签订经济合同，必须遵守国家的法律、政策及有关规定。第五条对外签订经济合同，除法定代表人外，必须是持有法人委托书的法人委托人。法人委托人必须对本企业负责，对本职工作负责，在授权范围内行使签约权。超越代理权限和非法委托人均无对外签约，但经总经理特别授权并发给委托证明收的例外。第六条签约人在签订经济合同之前，必须认真了解对方当事人的情况。包括：对方单位是否具有法人资格、有否经营权、有否履约能力及其资信情况，对方签约人是否法定代表人或法人委托人及其代理权限。做到既要考虑本方的经济效益，又要考虑对方的条件和实际能力，防止上当受骗，防止签订无效经济合同，确保所签合同有效、有利。第七条签订经济合同，必须贯彻“平等互利、协商一致、等价有偿”的原则和“价廉物美、择优签约”的原则。第八条签订经济合同，如涉及公司内部其他单位的，应事先在内部进行协商，统一平衡，然后签约。第九条经济合同除即时清洁者，一律采用书面格式，并必须采用统一的经济合同文本。第十条合同对方当事人权利、义务的规定必须明确、具体、文字表达要清楚、准确。合同内容应注意的主要问题是：

网络协议大全

网络协议大全在网络的各层中存在着许多协议，它是定义通过网络进行通信的规则，接收方的发送方同层的协议必须一致，否则一方将无法识别另一方发出的信息，以这种规则规定双方完成信息在计算机之间的传送过程。下面就对网络协议规范作个概述。 ARP（Address Resolution Protocol）地址解析协议它是用于映射计算机的物理地址和临时指定的网络地址。启动时它选择一个协议（网络层）地址，并检查这个地址是否已经有别的计算机使用，如果没有被使用，此结点被使用这个地址，如果此地址已经被别的计算机使用，正在使用此地址的计算机会通告这一信息，只有再选另一个地址了。 SNMP（Simple Network Management P）网络管理协议它是TCP/IP协议中的一部份，它为本地和远端的网络设备管理提供了一个标准化途径，是分布式环境中的集中化管理的重要组成部份。 AppleShare protocol（AppleShare协议）它是Apple机上的通信协议，它允许计算机从服务器上请求服务或者和服务器交换文件。AppleShare可以在TCP/IP协议或其它网络协议如IPX、AppleTalk上进行工作。使用它时，用户可以访问文件，应用程序，打印机和其它远程服务器上的资源。它可以和配置了AppleShare协议的任何服务器进行通信，Macintosh、Mac OS、Windows NT和Novell Netware都支持AppleShare协议。 AppleTalk协议它是Macintosh计算机使用的主要网络协议。Windows NT服务器有专门为Macintosh服务，也能支持该协议。其允许Macintosh的用户共享存储在Windows NT文件夹的Mac-格式的文件，也可以使用和Windows NT连接的打印机。Windows NT共享文件夹以传统的Mac文件夹形式出现在Mac用户面前。Mac 文件名按需要被转换为FAT（8.3）格式和NTFS文件标准。支持MAc文件格式的DOS和Windows客户端能与Mac用户共享这些文件。 BGP4（Border Gateway Protocol Vertion 4）边界网关协议-版本4 它是用于在自治网络中网关主机（每个主机有自己的路由）之间交换路由信息的协议，它使管理

如何实现合同的规范化管理

如何实现合同的规范化管理摘要：阐述了合同管理与企业稳步发展的关系，给出了规范合同管理的目的，并提出了加强规范化合同管理的途径。分析表明，加强企业合同管理可以有效地防范和化解经营风险，这对于企业经济活动的开展和经济利益的取得有着十分积极的意义。关键词：合同规范化管理在市场经济条件下，企业为实现一定的经济目的，明确相互权利义务关系就要签订合同，企业的一切行为都是由合同体现着，它不再是简单的要约、承诺、签约等内容，而是一种全过程、全方位、科学的管理，所以，一个企业的经营成败和合同管理有密切关系，现代企业若能对合同实施有效管理，将为企业管理水平和经济效益的提高产生巨大的推动力,促进企业稳步发展。 1.合同管理企业合同管理是指企业对以自身为当事人的合同依法进行订立、履行、变更、解除、转让、终止以及审查、监督、控制等一系列行为的总称。其中订立、履行、变更、解除、转让、终止是合同管理的内容；审查、监督、控制是合同管理的手段。 2.合同管理的规范化 2.1规避企业经营风险合同既是企业从事经济活动、取得经济效益的纽带，也是产生纠纷的根源。企业经营中的风险有许多是在合同的立项、订立和履行中发生的。合同管理首先要尽可能的发现签订某宗合同隐藏的风险。通过规范的合同管理，加强合同中立项的审查以慎重决策减少无利益投资；加强合同订立的管理可以减少合同订立过程中因个人疏漏产生的风险；加强合同履行中的控制可以保障合同利益得以更为及时、安全的实现；加强合同的备案与存档可以督促有关机构与人员更谨慎执行合同事务，防止风险。通过这一系列的措施，最大范围内确保收益的实现。 2.2 提升企业形象现代企业之间的竞争，不仅仅是产品质量、价格竞争，更重要的是企业信用，企业形象竞争。规范的合同管理毫无疑问的将使接触企业的人感受到合同管理中体现出的企业管理的规范与秩序，工作的严谨与守信，较高的法律意识和员工素质。从而提高企业的知名度和美誉度，提高竞争力，赢得市场，健康持久地发展下去。通过在合同管理制度中规定合同变更、解除的程序及合同履行、变更、解除应注意的问题，有助于企业员工树立良好的信用意识，严格履行已生效的合同，从而树立企业良好的商业信用及形象。

合同管理制度范本流程格式

内部管理制度系列合同管理制度流程格式（标准、完整、实用、可修改）

编号：FS-QG-67159合同管理制度流程格式 Model Contract Management System Process Format 说明：为规范化、制度化和统一化作业行为，使人员管理工作有章可循，提高工作效率和责任感、归属感，特此编写。公司合同管理办法 1目的规范集团公司合同管理程序，明确管理职责，界定管理层面，防范经营风险，提高管理效能。 2适用范围本制度适用于集团公司本部、分支机构和其他直属单位。集团公司全资、控股子公司依据法定程序执行。 3定义 3.1所属单位:特指集团公司所属各全资企业、其他直属单位，以及依照法定程序应当执行本制度的集团公司控股企业。 3.2合同:是指除劳动合同外，集团公司及其全资、控股成员企业及其他直属单位与平等主体的自然人、法人和其它

组织之间，以及集团内各平等主体之间设立、变更、终止民事权利义务关系的协议。 3.3合同管理:是指对合同立项、意向接触、资信调查、商务谈判、合同条款拟定、审查会签、签字、备案审核、履行、变更、中止、解除、纠纷处理、立卷归档等全过程的管理。 4管理体制、组织形式与相关规定 4.1合同管理实行分级归口管理与有限的集中控制相结合的管 -2- 理体制，具体组织形式包括: 4.1.1所属单位下列合同，如果是隶属于集团公司直接管理的项目，由集团公司相关业务主管部门审核同意后方可签订;非隶属于集团公司直接管理的项目，以及其他属于集团公司授权分支机构或其他直管单位管理的项目，需经具有相应管理权限的集团公司分支机构或其他直管单位审核同意后签订，并由审核或直接办理单位报集团公司备案。其中，需由集团公司提供担保的项目合同，应当经集团公司审核同

发票、合同管理规定

发票、合同管理制度一、目的根据目前公司合同、发票的管理状况，为了进一步规范公司各类合同、发票的管理，特制定本管理制度。二、适用范围总部及各分公司三、发票及收据的管理 1、发票的管理：（1）建立发票购买、发放、使用、作废、回款的发票管理台账，及时登记，以备查录。（2）发票的使用必须符合国家规定。（3）发票必须在财务保存，并由财务人员开具。（4）发票项目必须填写完整，不得向任何人提供无收款单位及金额的发票。（5）业务人员凭合同或收据到财务部门开具发票，发票所载客户与合同中所载客户及实际付款的客户单位名称必须一致，如不一致必须附上付款单位签章的代付款及委托开发票证明，否则所造成的税金损失由业务人员承担，开具发票后在此合同上注明“发票已开”字样。收据换发票，需同时交回收据。（6）如需先开具发票后收款，业务人员填写《先开发票后收款申请》，并经总裁（或营销总监）签字同意后方可开具。业务人员收款后需及时交回合同款项并取回《先开发票后收款申请》，财务人员在此申请上注明“款项收回”字样。若未将《先开发票后收款申

请》取回，则视同款项未收回处理。（7）未足额收到发票开具的款项，将发票交予客户时，需由客户在发票回执表上签字加盖公章，并开具欠条，加盖客户财务章。 (8) 若因合同不成功等原因款项未收回，一周内须将发票交回财务进行作废处理，原则上不能跨月，如未交回，按发票遗失处理。（9）如有特殊情况，对领出的发票，跨月申请作废的，对经办业务人员给予发票金额10％的处罚。（10）发票视同现金管理，如丢失发票，视情况对责任人进行处理，原则上需按票面金额将款项交至财务部，经由总裁审批处理决定。 2、收据的管理（1）收据的管理视同发票管理，建立收据管理台账，由公司财务部门统一进行。（2）对外开具的收据需加盖财务专用章，收据必需注明业务人员姓名、合同号、客户名称及金额，一式三联，一联由业务人员交客户，一联财务做为入账依据，一联随同合同统一保管。 3、发票回执业务人员在借出发票当月盘点日前必须将有客户盖章（公章或合同章）及接收人员签字之回执（格式见附件二）交回给公司财务，如无法按时交回符合规定的发票回执则视同发票遗失，办理相关责任承担手续。四、合同管理

合同管理制度范本共篇.doc

★合同管理制度范本_共10篇范文一：公司合同管理制度(范本)公司合同管理制度(范本) 一、目的为规范公司经济合同的管理，防范与控制合同风险，有效维护公司的合法权益，制定本制度。二、适用范围本制度适用于公司、所属各公司对外签订、履行的建立民事权利义务关系的各类合同、协议等，包括买卖合同、借款合同、租赁合同、加工承揽合同、运输合同、资产转让合同、仓储合同、服务合同等。三、职责（一）公司总经理负责公司销售、采购合同及其他经济合同的审批；（二）公司办公室负责公司各类合同的管理工作，具体职责是： 1、负责除销售、采购合同以外，其他各类合同的谈判工作并根据公司法定代表人的授权签订合同； 2、负责制定销售、采购合同统一文本； 3、负责对合同专用章、合同统一文本、法人授权委托书的发放和管理； 4、负责各部门提交的各类合同的合法性、可行性、有利性审查； 5、负责经济合同纠纷的处理； 6、负责经济合同的档案管理； 7、负责本制度的监督执行。

四、合同的签订（一）合同的主体订立合同的主体必须是公司及所属各公司中具有法人资格，能独立承担民事责任的组织，其他部门、机构、分公司等不得擅自签订合同。订立合同前，应当对对方当事人的主体资格、资信能力、履约能力进行调查，不得与不能独立承担民事责任的组织签订合同，也不得与法人单位签订与该单位履约能力明显不相符的经济合同。公司一般不与自然人签订经济合同，确有必要签订经济合同，应经公司总经理同意。（二）合同的形式订立合同，除即时交割（银货两讫）的简单小额经济事务外，应当采用书面形式。“书面形式”是指合同书、补充协议、公文信件、数据电文（包括电报、传真、电子邮件等），除情况紧急或条件限制外，公司一般要求采用正式的合同书形式。（三）合同的内容 1、当事人的名称、住所：合同抬头、落款、公章以及对方当事人提供的资信情况载明的当事人的名称、住所应保持一致。 2、合同标的：合同标的应具有唯一性、准确性，买卖合同应详细约定规格、型号、商标、产地、等级等内容；服务合同应约定详细的服务内容及要求；对合同标的无法以文字描述的应将图纸作为合同的附件。 3、数量：合同应采用国家标准的计量单位，一般应约定标的物数量，常年经销合同无法约定确切数量的应约定数量的确定方式（如电报、传真、送货单、发票等）。

通讯协议大全

现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。网络协议大全 1、ARP(address resolution protocol)地址解析协议 2、SNMP(simple network management P)网络管理协议，是TCP/IP的一部分 3、AppleShare protocol(AppleShare 协议) 4、AppleTalk 协议 5?、BOOTP协议(Bootstrap?Protocol)?应用一个基于TCP/IP协议的协议,该协议主要用于有无盘工作站的局域网 6、CMIP(Common Management Information Protocol)通用管理信息协议，它是建立在开放系统互连通信模式上的网络管理协议。相关的通用管理信息服务(CMIS)定义了访问和控制网络对象，设备和从对象设备接收状态信息的方法。 7、 DHCP协议、Dynamic?Host?Configuration?Protocol（动态主机配置协议），应用：在Windows中要启用DHCP协议，只要将IP地址设置为“自动获得IP地址”即可 9、Connection-oriented Protocol/Connectionless Protocol面向连接的协议/无连接协议 10 、Discard Protocol抛弃协议它的作用就是接收到什么抛弃什么，它对调试网络状态

公司合同管理工作总结

公司合同管理工作总结导读：本文是关于公司合同管理工作总结的文章，如果觉得很不错，欢迎点评和分享！【范文一：公司合同管理工作总结】合同管理工作是企业的一项重要管理内容，在市场经济日益发达的现代社会，企业的“守合同、重信用”已成为企业在市场竞争中不可或缺的重要品质之一。“守合同、重信用”是企业生存发展之本。我公司为全面规范合同管理水平，进一步规范和细化合同管理工作，做出了以下工作：一、加强学习宣传贯彻，提高合同管理人员的整体素质。培养和加强员工依法守信的观念。为适应合同审查、管理、监督工作的高标准、严要求的工作性质，更好地为企业生产经营服务，我公司企管部组织合同管理人员全面、系统地学习了《泰州市宏华冶金机械有限公司合同管理制度》，各部门、各经营人员加强信用责任意识和信用义务观念，熟悉国家有关法律、法规，提高业务水平，提高依法签订合同的能力和效率；公司定期开展合同管理规定的宣传，并在公司宣传栏通过出版墙报；并进行合同法规的系列讲座，在公司内部开展合同法竞赛；强调遵守合同的重要性；通过会议宣传依法组织生产经营活动的重要性。 2015年在公司领导重视和带动下，我公司员工坚持不懈的学习《合同法》及相关法律法规的学习，在全公司范围内形成了学好用好

《合同法》的新局面，同时为员工发放有关《合同法》的宣传材料，督促他们利用业余时间学习相关法律法规，强调遵守合同的重要性。我公司多次组织各级员工学习《合同法》和相关法律法规，及相关案例，强化合同管理人员职业素质教育和职业道德教育，严格规范合同审查工作人员行为，明确合同审查工作程序，依法履行合同审查工作职责，提升了合同管理战线的整体素质，为维护企业的正常经济秩序和企业利益奠定了基础。二、加强合同管理的组织机构建设，确保合同管理工作的有效实施。机构建设是创建“重合同守信用”企业的组织保证。我们首先做到了组织健全，机构完善，分工明确，职责到位。2009年开始，公司设立了专门的合同管理员岗位，由法律专业毕业的人员担任担任此岗。经过快五年多的岗位建设，成功起草并建立了公司完善的合同管理体系，建立健全了各项规章管理制度，对照《合同法》的有关规定及时调整、修订适合本企业、本行业特点的合同管理制度。形成了以合同签订审批流程、授权委托制度、印章的使用、合同的拟定为架构的合同管理体系。《合同管理规定》明确了合同的审批签订、合同的履行、合同的变更、解除、合同纠纷的处理等合同的日常管理工作和罚责作了详细的规定。我公司建立的科学、合理、切实可行的合同管理制度，在对内管理上发挥了重要的作用，通过成立了合同管理制度，形成了由总经理负总责，分管领导分工负责，设专职合同管理员，做到了定机构、定人员、定岗位、定职责；并有健全的合同台帐、保持完整的合同档案。

(完整版)公司合同管理制度范本

中小企业合同管理制度（范本）一、合同管理总则 1、目的和依据为加强公司的合同管理工作，预防、减少和及时解决合同纠纷，维护企业合法权益，提高经济效益，根据《中华人民共和国合同法》和有关政府部门规定，结合公司的实际情况，制定本制度。 2、适用范围本制度适用于公司及其所属各单位与各法人单位、其他经济组织、自然人或相互之间签订的各类合同、协议等，包括但不限于买卖合同、借款合同、租赁合同、加工承揽合同、运输合同、资产转让合同、仓储合同、服务合同、保险合同等。 3、合同管理原则合同管理必须遵循依法办事，预防为主，层层把关，跟踪监督，及时调处，维护企业合法权益的原则。签订、履行、变更、解除合同，必须遵守《中华人民共和国合同法》及有关法律、法规、规章，参照有关政策。 4、保守商业秘密管理、参与合同工作的一切有关人员，应当为公司保守商业秘密。二、合同管理职责 1、企业合同管理部门（法务部）的主要合同管理职责 1）、认真学习、贯彻执行《中华人民共和国合同法》和有关条例，依法保护本企业的合法权益。 2）、制定、修订本公司合同管理制度、办法，组织实施合同管理工作。 3）、审查合同，防止不完善或不合法的合同出现。 4）、协助合同承办人员依法签订合同，参与重大合同的谈判与签订。 5）、做好合同统计、归档、保管工作。 6）、监督、检查本公司合同签订、履行情况。 7）、宣传合同法和有关法规，培训合同管理人员和业务人员、采购人员。8）、依法处理本公司的合同纠纷。 9）、制止公司或个人利用合同进行违法活动。 10）、按期统计、汇总本公司合同签订、履行以及合同纠纷处理情况并向公司领导汇报。 2、供销部门的主要职责 1）、依法签订、变更、解除本部门的合同。 2）、严格审查本部门所签订的合同，重大合同提交有关方面会审。 3）、对所签合同，认真执行，并定期自查合同履行情况。 4）、在合同履行过程中，加强与其它各有关部门联系，发生问题及时向法务部通报。 5）、本部门合同的登记、统计、归档工作。 6）、协助法务部对合同纠纷的处理。 3、财务部门的主要职责 1）、加强与供销等有关部门的联系，及时通报合同履行中的应收应付情况。2）、做好与合同有关的应收应付款项的统计、分析，提出处理建议、妥善保管收、付凭证。 3）、配合法务部做好合同管理工作。

关于进一步规范合同管理工作的通知

宣威供电有限公司通知通知〔2014〕27号签发人：浦承勇2014年1月24日关于进一步规范合同管理工作的通知公司所属各部门：合同管理工作既是防范经营管理风险，解决纠纷的主要方式和依据，又是各部门加强规范化管理工作的需要。为进一步提高合同管理的工作质量，现将有关事项通知如下：一、当前合同管理存在的问题（一）合同风险管理意识不强。有关部门未充分认识到合同是法律化了的文书，是当事人之间依法确定、变更、终止民事权利义务关系的协议，是处理纠纷的主要依据，而有关部门仅仅把合同当成实现资金支付的一种方式，因而，在合同的起草、审查、履行、变更、续订、解除、纠纷处理等多个方面没有加以严格管理，致使合同管理较多流于形式。（二）合同类型的选择不准确。承办部门在起草合同时，虽然参考了行业、网、省公司出台的合同范本，但针对某一具体事

项的约定，未能及时分辨出合同类型，合同类型选择的错误，导致合同在履行中产生相应的法律风险。如常见的建设工程施工合同与承揽合同、承揽合同与委托合同等，常常出现区别分类适用错误。（三）合同文本、形式及内容不规范。在承办部门所使用的合同文本中，不时会出现使用对方当事人提供的合同文本，初步审查不难发现，对方提供的合同文本的约定内容不仅不能实现公司交易的目的，而且在纠纷产生时不利于维护自身合法权益；在形式方面，从合同版面信息填写至合同文本的草拟、修改，未严格按照招标（非招标）以及所要实现的交易目的来填写；在内容方面，各承办部门过分死板、僵化的使用合同范本，未结合公司的实际以及合同的要求来加以修改、完善，主要集中在：质量条款、责任划分、违约责任、法院管辖方面。（四）合同流转缓慢。相关审查会签部门没有严格按照《云南电网公司合同管理实施细则》（2013版）第“5.3.5”项规定的时限进行审查。（五）合同审查会签时未按照审查职责及要求进行审查和出具正确会签意见。承办部门在草拟合同前应当审查签约方哪些方面？审查会签部门在审查合同时应当履行什么样的职责，应当审查合同的哪些内容？《云南电网公司合同管理实施细则》（2013版）对这些职责及要求已作了明确界定。但至现在，各承办及会签部门仍未按照其规定履行相应的职责，并且，在合同起草及会签时大都出具“同意”意见。（六）倒签合同严重。倒签合同是指合同双方在合同签订

《网络协议分析》课程标准

《网络协议分析》课程标准课程名称、代码：网络协议分析、总学时数：36（理论课学时数：18 实践课学时数：18）学分数：2 适用专业：计算机网络技术、计算机应用技术一、课程的性质 1、必修课； 2、专业课。二、课程定位该课程是作为计算机网络技术专业和计算机应用专业的专业必修课。通过该门课的学习，使学生深入学习TCP/IP协议体系结构和基本概念，分析各个协议的设计思想、流程及其所解决的问题。通过该门课程的学习，进一步提高学生作为网络管理员的技能水平。学生能够胜任中小型企业的网络维护的日常工作。学生应先修《计算机网络基础》一课，掌握计算机网络技术的基础知识后，方可修此门课程。三、课程设计思路本课程的设计思路是以计算机专业学生就业为导向，着重培养学生的动手能力。通过调查研究社会对计算机专业学生在网络安全技术方面的要求，制定相关的理论教学内容和实践内容。课程整体结构按照网络管理员工作岗位所涉及到的工作任务，维护中小型局域网正常运作、检测网络故障等工作技能的培养安排课程项目。在学时分配上，理论课时与实践课时各占一半，注重实践教学，有利于提高学生的动手能力，同时也加深了对理论知识的理解，做到知其然并知其所以然。四、课程基本目标 1、知识目标：（1）知道TCP/IP协议以及工作原理；（2）知道PPP协议以及工作原理；（3）知道Internet地址及地址解析；（4）知道IP协议以及工作原理；（5）知道ICMP协议以及工作原理；（6）知道UDP协议以及工作原理；（7）知道TCP协议以及工作原理；（8）知道Internet地址扩展技术。 2、职业技能目标：（1）能分析PPP协议；（2）能分析ARP协议；（3）能分析IP协议；（4）能分析ICMP协议；（5）能分析UDP协议；（6）能分析TCP协议；（7）能分析HTTP协议。 3、职业素质养成目标

网络协议大全 VTP、RGMP

网络协议大全 VTP、RGMP VTP：思科VLAN中继协议(VTP：CiscoVLANTrunkingProtocol) VLAN中继协议(VTP)是思科第2层信息传送协议主要控制网络范围内VLANs的添加、删除和重命名VTP减少了交换网络中的管理事务当用户要为VTP服务器配置新VLAN时可以通过域内所有交换机分配VLAN这样可以避免到处配置相同的VLANVTP是思科私有协议它支持大多数的CiscoCatalyst系列产品通过VTP其域内的所有交换机都清楚所有的VLANs情况但当VTP 可以建立多余流量时情况例外这时所有未知的单播(Unicasts)和广播在整个VLAN内进行扩散使得网络中的所有交换机接收到所有广播即使VLAN中没有连接用户情况也不例外而VTPPruning技术正可以消除该多余流量缺省方式下所有CiscoCatalyst交换机都被配置为VTP服务器这种情形适用于VLAN信息量小且易存储于任意交换机(NVRAM)上的小型网络对于大型网络由于每台交换机都会进行NVRAM存储操作但该操作对于某些点是多余的所以在这些点必须设置一个“判决呼叫(JudgmentCall)基于此网络管理员所使用的VTP服务器应该采用配置较好的交换机其它交换机则作为客户机使用此外需要有某些VTP 服务器能提供网络所需的一定量的冗余到目前为止VTP具有三种版本其中VTPv2与VTPv1区别不大主要不同在于：VTPv2支持令牌环VLANs而VTPv1不支持通常只有在使

用TokenRingVLANs时才会使用到VTPv2否则一般情况下并不使用VTPv2 VTPv3不能直接处理VLANs事务它只负责管理域(AdministrativeDomain)内不透明数据库的分配任务与前两版相比VTPv3具有以下改进：支持扩展VLANs 支持专用VLANs的创建和广告提供服务器认证性能避免“错误数据库进入VTP域与VTPv1和VTPv2交互作用支持每端口(OnaPerPortBasis)配置支持传播VLAN数据库和其它数据库类型 RGMP：思科路由器端口组管理协议(RGMP：CiscoRouterPortGroupManagementProtocol) 思科路由器端口组管理协议(RGMP)弥补了Internet组管理协议(IGMP：InternetGroupManagementProtocol)在Snooping技术机制上所存在的不足RGMP协议作用于组播路由器和交换机之间通过RGMP 可以将交换机中转发的组播数据包固定在所需要的路由器中RGMP的设计目标是应用于具有多种路由器相连的骨干交换网(BackboneSwitchedNetworks) IGMPSnooping技术的局限性主要体现在：该技术只能将组播流量固定在接收机间经过其它交换机直接或间接相连的交换端口在

合同管理办法范本

合同管理办法 1．总则 1.1为了加强合同管理，预防纠纷，避免损失，维护长庆事业部的合法权益，根据《中华人民共和国合同法》、国家有关法律法规和中国石油集团测井有限公司有关规定，结合长庆事业部实际，制定本办法。 1.2本办法适用于长庆事业部（以下简称事业部）与平等主体的自然人、法人、其他组织（以下统称对方）之间设立、变更、终止民事权利义务关系的合同。主要有以下合同：测井技术服务合同，买卖合同，供用电、水、气、热力合同，租赁合同，承揽合同，建设工程合同，运输合同，技术合同，委托合同。 1.3订立、履行合同，应当遵守法律、行政法规，尊重社会公德，不得扰乱社会经济秩序，不得损害社会公共利益，不得损害事业部的合法权益。 2．合同管理部门及其职责 2.1市场部为合同管理部门，统一负责事业部合同管理工作。 2.2合同管理职责是： 2.2.1统一管理事业部合同，指导、检查、监督和考核事业部下属各单位合同管理工作； 2.2.2制定和修改事业部合同管理办法及有关制度，并负责监督实施； 2.2.3审查对方的资信情况、履约能力和合同的合法性； 2.2.4指导事业部承办人员办理合同审批手续，审查合同签订，监督合同履行，审查合同结算； 2.2.5指导事业部承办人员办理合同鉴证、公证，处理合同纠纷； 2.2.6主持重大合同的洽谈、起草和签订工作； 2.2.7主持事业部招标工作和负责事业部投标事宜； 2.2.8对事业部代理人进行资格许可管理，组织业务培训，颁发《签订合同资格证书》； 2.2.9对事业部承办人员工作业绩进行考核，对《签订合同资格证书》进行年度考核注册； 2.2.10统一管理和正确使用“中国石油集团测井有限公司合同专用章（长庆1）（长庆2）”、“中国石油集团测井有限公司长庆事业部合同审查章”、《签订合同委托代理证书》、《合同审查审批表》、《合同评审会签记录》（CQCJ/JL7.2-03）、《合同结算通知单》和合同示范文本； 2.2.11健全合同管理基础资料，按规定向有关部门上报资料； 2.2.12整理合同文本和合同管理基础资料，按规定归档保存。 3．职能部门业务审查范围 3.1市场部审查范围及适用合同： 3.1.1审查合同项目是否有计划、是否有资金预算。

(完整word)通讯协议大全,推荐文档

TCP/IP TCP/IP是网络中使用的基本的通信协议。 TCP/IP协议包括TCP、IP、UDP、ICMP、RIP、TELNETFTP、SMTP、ARP、TFTP等许多协议，这些协议一起称为TCP/IP协议。 IPX/SPX(多用于局域网) 是基于施乐的XEROX’S Network System（XNS）协议，而SPX是基于施乐的XEROX’S SPP（Sequenced Packet Protocol：顺序包协议）协议 NetBEUI 即NetBios Enhanced User Interface，或NetBios增强用户接口。网络通信协议： RS-232-C、RS-449、V.35、X.21、HDLC 简单网络管理协议：简单网络管理协议SNMP、点到点协议PPP 3G标准： WCDMA（欧洲版）、CDMA2000（美国版）和TD-SCDMA（中国版） Modbus协议 Modbus就是工业控制器的网络协议中的一种包括ASCII、RTU和TCP 现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。

网络协议大全 1、ARP(address resolution protocol)地址解析协议 2、SNMP(simple network management P)网络管理协议，是TCP/IP的一部分 3、AppleShare protocol(AppleShare 协议) 4、AppleTalk 协议 5 、BOOTP协议(Bootstrap Protocol) 应用一个基于TCP/IP协议的协议,该协议主要用于有无盘工作站的局域网 6、CMIP(Common Management Information Protocol)通用管理信息协议，它是建立在开放系统互连通信模式上的网络管理协议。相关的通用管理信息服务(CMIS)定义了访问和控制网络对象，设备和从对象设备接收状态信息的方法。 7、DHCP协议、Dynamic Host Configuration Protocol（动态主机配置协议），应用：在Windows 中要启用DHCP协议，只要将IP地址设置为“自动获得IP地址”即可 9、Connection-oriented Protocol/Connectionless Protocol面向连接的协议/无连接协议 10 、Discard Protocol抛弃协议它的作用就是接收到什么抛弃什么，它对调试网络状态的一定的用处。 11、POP3(Post Office Protocol Version 3)邮局协议-版本3 12、PPP(Point to Point Protocol)点对点协议 13、RIP(Routing Infomation Protocol)路由信息协议 14、SLIP(Serial Line Internet Protocol)串行线路Internet协议、 15、LMTP(Local Mail Transfer Protocol)本地邮件传输协议 16、STP(Simple Mail Transfer Protocol)简单邮件传送协议 17 、Echo Protocol协议这个协议主要用于调试和检测中。这个协议的作用也十分简单，接收到什么原封发回就是了。、 18 、FTP(File Transfer Protocol)文件传输协议、 19 、HDLC(High-Level Data Link Control)高层数据链路协议、 20、HTTP1.1(Hypertext Transfer Protocol Vertion 1.1)超文本传输协议-版本1.1 21、HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议、 22、ICMP(Internet Control Message Protocol)Internet控制信息协议 23、IMAP4(Internet Mail Access Protocol Version 4)Internet邮件访问协议-版本4 24、NNTP(Network News Transfer Protocol)网络新闻传输协议 25、NNTP同POP3协议一样，也存在某些局限性。 26、IOTP(Internet Open Trading Protocol)Internet开放贸易协议 27、IPX/SPX(Internetwork Packet Exchange/Sequential PacketExchange)互连网包交换/顺序包交换、 Talk协议

规范合同管理,规避合同风险

规范物资合同管理规避合同风险随着我国市场经济体制的不断完善，市场主体的行为逐步规范化、法治化，合同管理在企业管理和项目管理中的地位和作用日益重要和突出，企业或项目的采购风险也随之增加。物资采购的环节虽然不复杂，但是采购的各个环节中却存在各种不同的风险，如果企业或项目物资管理人员对合同风险认识不足、防范不力，将给企业或项目带来巨大的经济损失，这就要求企业或项目部的物资管理人员进一步加强合同管理意识、法律意识和项目管理意识，保证企业物资采购时刻保持在在健康平稳的轨道上运行。一、物资合同管理存在问题 1、合同签订条件不齐备时签订采购合同。项目刚开工，市场还未完全调查清楚，技术部门图纸未到，设计数量不准确，符合技术规格要求的厂家少时签订框架合同，对单价、数量和金额基本无约束力的合同，合同履行中容易引起频繁调价和质量方面的纠纷。 2、签订合同内容存在缺陷。物资合同没有按照公司合同范本签订或者对合同范本条款随意修改，与供应商签订合同存在条款不清、内容不完备、文字表达不严谨，缺项漏项、对关键条款几乎不作约定，或者约定简单，导致合同难以履行，一旦发生合同纠纷，给企业造成损失。

3、供应商选择过程不规范，与供货能力差，规模小、信誉差供应商签订合同，供货速度不能满足现场施工，断货、缺货、供应产品质量不合要求，以次充好，缺斤少两，容易引起的停工待料和合同纠纷。 4、合同履行中，材料供方签订合同单位与实际供货单位和收款单位不一致。A公司与项目签订合同后，有代理人与项目联系供货，项目付款给代理人的情形，或者代理商借用资质与项目部签订合同后，未经合同签订人同意变更收款人、收款方式，导致合同付款完成后，签订人与企业发生纠纷，给企业带来损失。 5、供应商合同欺诈。项目部上场后，供应商通过各种途径最终与项目部签订供货合同，将合同中供应材料转让给他人，因不具备供货能力而停止供货，最终伙同第三方欺诈项目部。 6、供应商迟延履约或不能履约，项目部多次催告都无法履约的，项目部未及时以书面等固定可查方式与供货商解除合同，导致项目部与其他供应商合作后，我方被诉讼违约面临赔偿。 7、经济税务风险，供应商提供的业务数据、发票等，不真实不合法。二、应对合同风险管理的措施

合同管理办法制度范本格式

合同管理办法 1 目的为规范本公司合同的管理，避免和减少因合同管理不当造成的损失，维护经济秩序，提高经济效益，根据国家的有关法律、法规，结合本公司实际情况，特制定本办法。 2 适用范围适用于公司与其他法人或组织签订的经济合同、技术合同等，公司参股、控股的具有法人资格的其他组织应参照本办法另行制定合同管理办法。 3 规范性引用文件 Q/GDCF A101.001-2003 《质量、职业健康安全、环境管理手册》 Q/GDCF A202.002-2003 《采购管理控制程序》 4 职责 4.1 合同管理实行业务管理原则和法律归口管理的原则，公司范围内各种经济活动中，金额在1万元（含1万元）以上的，均应签订经济合同。 4.2 物资部、综合管理部以及计划部是合同主要管理部门，负责组织商务谈判、起草合同、组织评审及提交公司领导签订合同等。 4.3 工程部或生产准备部负责提出或审核有关合同中工程技术质量要求、设备的规格型号和质量要求以及工程及物资的验收标准等。 4.4 计划部对合同经济条款进行审核。 4.5 财务部可参与重要合同的商务谈判，并进行财务审核。 4.6 综合管理部（审计）或委托审计事务所对公司经济合同条款等进行审计。 4.7 综合管理部（法律事务）或委托法律顾问对合同与协议的合法性、规范性进行审查。 5 管理内容与要求 5.1 计划部、物资部以及综合管理部负责承办合同的范围： 5.1.1 物资部负责承办的合同，包括： ——设备、原辅材料购销合同； ——生产性低值易耗品采购合同； ——非标设备加工承揽合同； ——货物仓储保管合同； ——货物运输合同； ——货物保险合同； ——行政管理所涉及的形成固定资产的低值易耗品的货物采购合同。 5.1.2 综合管理部负责承办的合同，包括： ——劳动合同； ——专业技术培训合同； ——法律咨询合同； ——审计事务采购合同； ——广告、宣传合同； ——后勤管理合同； ——绿化维护合同； ——行政管理涉及的不形成固定资产的非生产性低值易耗品的货物采购合同。

重点掌握网络协议标准规范大全

重点掌握网络协议标准规范大全在网络的各层中存在着许多协议，它是定义通过网络进行通信的规则，接收方的发送方同层的协议必须一致，否则一方将无法识别另一方发出的信息，以这种规则规定双方完成信息在计算机之间的传送过程。下面就对网络协议规范作个概述。 ARP(Address Resolution Protocol)地址解读协议它是用于映射计算机的物理地址和临时指定的网络地址。启动时它选择一个协议(网络层)地址，并检查这个地址是否已经有别的计算机使用，如果没有被使用，此结点被使用这个地址，如果此地址已经被别的计算机使用，正在使用此地址的计算机会通告这一信息，只有再选另一个地址了。 SNMP(Simple Network Management P)网络管理协议

它是TCP/IP协议中的一部份，它为本地和远端的网络设备管理提供了一个标准化途径，是分布式环境中的集中化管理的重要组成部份。 AppleShare protocol(AppleShare协议) 它是Apple机上的通信协议，它允许计算机从服务器上请求服务或者和服务器交换文件。AppleShare可以在TCP/IP协议或其它网络协议如IPX、AppleTalk上进行工作。使用它时，用户可以访问文件，应用程序，打印机和其它远程服务器上的资源。它可以和配置了AppleShare协议的任何服务器进行通信，Macintosh、Mac OS、Windows NT和Novell Netware都支持AppleShare协议。 AppleTalk协议它是Macintosh计算机使用的主要网络协议。Windows NT服务器有专门为Macintosh服务，也能支持该协议。其允许Macintosh的