Bi-Directional Safety Analysis for Product-Line, Multi-Agent Systems
Josh Dehlinger Department of Computer Science Iowa State University
226 Atanasoff Hall
Ames, IA 50011
1 515-294-2735
dehlinge@https://www.doczj.com/doc/af5395509.html,
Robyn R. Lutz Department of Computer Science Iowa State University and
Jet Propulsion Laboratory/Caltech 226 Atanasoff Hall
Ames, IA 50011
1 515-294-3654
rlutz@https://www.doczj.com/doc/af5395509.html,
ABSTRACT
Safety-critical systems composed of highly similar, semi-autonomous agents are being developed in several application domains. An example of such multi-agent systems is a fleet, or “constellation” of satellites. In constellations of satellites, each satellite is commonly treated as a distinct autonomous agent that must cooperate to achieve higher-level constellation goals. In previous work, we have shown that modeling a constellation of satellites or spacecraft as a product line of agents (where the agents have many shared commonalities and a few key differences) enables reuse of software analysis and design assets. We have also previously developed efficient safety analysis techniques for product lines.
We now propose the use of Bi-Directional Safety Analysis (BDSA) to aid in system certification. We extend BDSA to product lines of multi-agent systems and show how the analysis artifacts thus produced contribute to the software’s safety case for certification purposes. The product-line approach lets us reuse portions of the safety analysis for multiple agents, significantly reducing the burden of certification. We motivate and illustrate this work through a specific application, a product-line, multi-agent satellite constellation.
Categories and Subject Descriptors
I.2.11 [Artificial Intelligence]: Distributed Artificial Intelligence – multi-agent systems D.2.4 [Software Engineering]: Software/Program Verification – reliability D.2.1 [Software Engineering]: Requirements/Specifications
General Terms
Design, Reliability, Verification Keywords
Software safety, multi-agent systems, product-line engineering, system certification
1.INTRODUCTION
The emergence of distributed systems (e.g., formation flying of satellite constellations) as a viable and reliable architecture for mission-critical domains coupled with the advantages of adopting an agent-oriented perspective for software development has led to a number of proposed systems combining these two concepts. A multi-agent system (MAS) is an application “designed and developed in terms of autonomous software entities that can flexibly achieve their objectives by interacting with one another in terms of high-level protocols and languages” [24]. Actual proposed systems including the Terrestrial Planet Finder-I (TPF-I) spacecraft [22] and the TechSat-21 [3], Sun-Solar System Connection, Search for Earthlike Planets and Universe Exploration all rely on constellation missions to achieve their scientific goals [18]. Agent-oriented software engineering (AOSE) appears be an appropriate software development methodology for such systems [21].
Certification is a process whereby a certification authority determines if an applicant provides sufficient evidence concerning the means of production of a candidate product and the characteristics of the candidate product so that the requirements of the certifying authority are fulfilled [11, 13, 19, 20]. Software safety analysis techniques, similar to those used in this work, have previously been shown to contribute to the certification of software-intensive systems in [1, 16]. However, little work has been specifically aimed at software product lines of MAS. A software product line is defined as a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission [23]. The work presented here tailors the safety analysis techniques to a particular AOSE methodology, Gaia, to support certification of product-line, agent-based systems.
The main contribution of this paper is to extend Bi-Directional Safety Analysis (BDSA) to product line MAS and show how the analysis artifacts thus produced contribute to the software’s safety case for certification purposes. The product-line approach allows
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
ITCES’06, April 4, 2006, San Jose, California, USA.
Copyright 2006 ACM 1-58113-000-0/00/0004…$5.00.
us to reuse portions of the safety analysis assets for multiple, similar agents, significantly reducing the burden of certification. First, we further the inclusion of safety analysis techniques into AOSE by providing a structured process to perform a Software Failure Modes, Effects, Criticality Analysis (SFMECA) for safety-critical, product-line MAS. The SFMECA is reusable for other agents in the system since our approach incorporates the product-line vision of a MAS from [6].
Second, safety analysis techniques contribute to system certification of product-line MAS by verifying software design compliance with reliability, robustness and safety standards. Because the safety analysis is performed on the product line as a whole (rather than serially on each individual product-line member), the safety analysis assessment techniques described in this work may significantly reduce the time and cost of certifying a safety-critical MAS.
This paper illustrates the process and contributions of this work using an agent-based implementation of a satellite constellation loosely based on the requirements for the TechSat21 [3, 21]. TechSat21 was a proposed mission, originally scheduled to launch in January 2006 but cancelled in late 2003 with much of the software reused on a subsequent mission [4]. It was designed to explore the benefits of a distributed, cooperative approach to satellites employing agents [3].
The remainder of this paper is organized as follows. Section 2 reviews background and related work in software safety analysis techniques and product-line MAS. Section 3 details our approach in utilizing the BDSA technique for safety-critical, product-line MAS to assist in certifying the composite system. Finally, Section 4 provides concluding remarks and future research directions.
2.BACKGROUND AND RELATED WORK The research presented here integrates existing work in software safety analysis with software engineering for multi-agent systems (MAS) to aid in system certification. Certification may apply to the development process, the developer or the actual product [16]. Since it is insufficient to certify the process or developer for the software of safety-critical systems, building a safety case that provides “an argument accompanied by evidence that all safety concerns and risks have been correctly identified and mitigated”
[10] aids in the certification of the product. Further, this work builds upon our previous work of integrating the reuse potential of safety analysis assets into the design and development of product-line MAS.
2.1Software Safety Techniques
Software safety analysis centers on the investigation of how software can jeopardize or contribute to the safety of the system [15]. Two common techniques used in software safety analysis are Software Failure Modes, Effects and Criticality Analysis (SFMECA) and Software Fault Tree Analysis (SFTA). Bi-Directional Safety Analysis (BDSA) combines these two techniques in order to provide both a forward analysis to determine systems effects of software failure modes to effects on the systems and to determine if those failure modes are possible in the system to be certified [16]. SFMECA is a tabular, forward (inductive) search technique that starts with the failure of a component or subsystem and then looks at its effect on the overall system [15]. In [17], a list of generic failure-mode guidewords is given to aid in the process of constructing a SFMECA for failure in data communication and event processing. These guidewords, when applied to the failure of a component or subsystem, help engineers systematize the process of determining the possible effects of each failure mode on other components of the system that could lead to a hazard(s). SFTA is a tree-based, backward (deductive) technique that typically has as its root node a system-wide, catastrophic event [15]. Analysis proceeds by determining the set of necessary preconditions causing the occurrence of the hazard. The set of possible causes are connected to the parent node by logic gates to describe their contributing relation. This process continues through each level of the constructed subtree until basic events are reached or until the desired level of subsystem detail is achieved.
A technique to cleanly extend SFTA to software product lines was introduced in [8]. A SFTA can be constructed for an entire product line and product-line members’ fault trees can be derived from the product-line SFTA. PLFaultCAT, a graphical tool to construct a product-line SFTA, exploits this technique and then allows users to automatically derive a product-line members’ fault tree given the variabilities to be included [8].
BDSA combines a search from potential failure modes to their effects with a search from possible hazards to the contributing causes of each hazard [17]. Although BDSA does not require SFMECA and SFTA to be used as the forward and backward search, respectively, we follow [12] and [16] in using these techniques in our BDSA.
2.2Software Safety Techniques
Reuse of software-engineering assets continues to be a demand on software system development methodologies. Software product-line engineering models provide software engineers a reuse-conscious development platform that can contribute to significantly reducing both the time and cost of software requirements specification, development, maintenance and evolution [5]. In a product line, the common, managed set of features shared by all members is the commonalities. The members of a product line may differ from each other via a set of allowed features not necessarily found in other members of the product line (i.e., the variabilities).
Agent-oriented software engineering (AOSE) has provided tools and techniques allowing for natural, high-level abstractions in which software developers can understand, model and develop complex systems [24]. Several AOSE methodologies have been proposed for various types of application domains including Tropos [2] and MaSE [9]. We selected Gaia [24] as the AOSE design methodology with which to incorporate safety analysis because of its extensive documentation and acceptance in the AOSE community.
The Gaia methodology centers on defining an agent based upon the role(s) that it can assume. Each role’s requirements specification is defined by its protocols (i.e., defines how agents interact), activities (i.e., the computations associated with the role that can be executed without interacting with other agents), permissions (i.e., the information resources that the role can read,
change and generate) and responsibilities (i.e., the liveness and safety properties the role must ensure).
Using the Gaia methodology, Dehlinger and Lutz applied the notion of an agent having different possible levels of intelligence for a given role to investigate the reuse advantages of product-line engineering in developing multi-agent systems (MAS) [6]. For example, a role in a distributed system of nodes, depending on its environment and context, may have one of the following levels of intelligence:
?I4: receive/execute commands
?I3: local planning and receive/execute commands
?I2: local planning, interaction, partial system-knowledge and receive/execute commands
?I1: system-level planning, interaction, full systems-knowledge and receive/execute commands
The level of intelligence for a role may dynamically change during run-time depending on the system’s organization and/or goals. For example, at any given time only a single agent in a distributed system may have role X operating at intelligence level I1. However, several other agents with role X may operate at intelligence level I3 but be capable of dynamically increasing the role’s intelligence level to I1 if needed (i.e., a hot-spare/warm-spare concept). Similarly, some agents with role X may be restricted to operating only in I4 or I3 due to resource constraints or design decisions. Adopting this view, a MAS can be designed using the notions of product-line engineering to fully take advantage of the reuse principles inherent in product lines.
In [7], it was shown how safety analysis can ensure the safety and reliability of product-line MAS using SFTA. This work extends [7] to include a SFMECA safety analysis enabling BDSA for product-line MAS. 3.APPLYING BI-DIRECTIONAL SAFETY ANALYSIS TO MULTI-AGENT SYSTEMS The use of Bi-Directional Safety Analysis (BDSA), detailed in Section 3.3, requires the use of forward and backward searches. In this work, we use Software Failure Modes, Effects and Criticality Analysis (SFMECA), discussed in Section 3.1, and Software Fault Tree Analysis (SFTA), discussed in Section 3.2, as the forward and backward search technique, respectively.
Using the Gaia methodology [24], we situate the safety analysis step, shown in Figure 1, as using the software engineering assets (i.e., the Role Schema) of the “Analysis and Design” phase but also augmenting the requirements specifications of the “Analysis and Design” phase. Thus, the safety analysis, in addition to generating safety analysis assets (e.g., SFMECA tables, software fault trees, etc.) used to make a safety case for the software during system certification, aids in verifying the safety requirements and discovering safety requirements missed in the initial requirements specification. Again, because the multi-agent system (MAS) is viewed as a product line, the safety analysis is providing safety case assets for any product line member.
In the Analysis and Design phase of the Gaia methodology [24], the software engineer specifies the requirements in a Role Schema, shown in Figure 2, when constructing a product-line MAS. Safety requirements for a role are listed in the form of safety properties that the agent must ensure in the Responsibilities section. However, Gaia provides no structured way by which to discover safety requirements. Similarly, Gaia provides no process by which to check that the safety requirements suffice to mitigate possible hazards. In the following sections, we detail how performing BDSA can help verify and complete the safety properties that a role must guarantee.
Figure 1. An overview of our process situated in the Gaia-based product-line approach in developing MAS.
Role Schema: Cluster Allocation Planner Schema ID: F32-I1
Description:
Assigns a new cluster configuration by assigning new satellite positions
within the cluster. This is done to equalize fuel use across the cluster. With
the I1 intelligence level, it is able to send cluster assignments to other
satellites (i.e., spacecraft level agents) in order to arrange a new cluster configuration. This may occur when a new satellite is added or in the case
of a failure of a satellite.
Protocols and Activities:
CalculateDeltaV, UpdateClusterInformation, MoveNewPos, DeOrbit,
AssignCluster, AcceptDeltaVBids, RequestDeltaVBids,
SendMoveNewPosMsg, SendDeOrbitMsg
Permissions:
Reads -
p osition // current satellite position
velocityIncrement // current satellite velocity increment
supplied satelliteID // satellite identification number
supplied velocityIncrment // satellite velocity increment
Changes -
position// current satellite position
velocityIncrement // current satellite velocity increment
Generates -
newPositionList // new position list to assign to the
// satellites within the cluster
Responsibilities:
Liveness -
Optimize the fuel use across the cluster.
Safety -
Prevent satellite collisions during a new cluster configuration.
Figure 2. An example of the requirements specification for a role of the TechSAT21 satellite constellation
specified as a product line in Gaia’s Role Schema.
3.1Forward Search Safety Analysis
The forward analysis uses a Software Failure Modes, Effects and Criticality Analysis (SFMECA). Gaia’s Role Schema conveniently partitions a role’s requirements specifications into events (functionality) that the role can perform and data that the role can access. Like [12], we partition the SFMECA into separate analyses on the data and events. We use guidewords of [16] to steer our investigation into the possible failures within a product-line multi-agent system (MAS). We here describe first the construction of the SFMECA event table for the Gaia Role Schema and then the construction of the SFMECA data table. Each activity of a role (the non-underlined keywords listed in Gaia’s Role Schema under the Protocols and Activities section) is essentially an event (i.e., some functionality) that the role can execute. To construct a SFMECA table for the events that a role can execute, as in a standard SFMECA we use the following keywords to guide our analysis: “halt/abnormal termination”, “omission”, “incorrect logic/event” and “timing/order”. Because the role definition depends on its variation point in the Role Schema, detailed in full in [6], the derived SFMECA captures the possible event and data failures for all the near-identical satellites. Figure 3 gives an example of a partial SFMECA entry for the MoveNewPos activity for our TechSAT21 example, an event causing a satellite to alter its position in the constellation.
The procedure to construct a SFMECA table for the events from the Role Schema using the event guidewords consists of the following steps:
For each role:
For each activity listed in the Protocols and Activities section of the Role Schema:
a.Provide the event name in the appropriate column.
b.Apply each of the keywords (“halt/abnormal
termination”, “omission”, “incorrect logic/event” and
“timing/order”) to the event. For each keyword:
Role Event Event Failure
Mode
Local Effect System Effect Criticality Halt/Abnormal
Termination
The position? velocityIncrement
and newPositionList data may be
temporarily incorrect since the
satellite did not complete moving
to its new position. This could
potentially affect other events such
as UpdateClusterInformation and
CalculateDeltaV.
The satellite will not
have moved to the
position expected by
other satellites in the
cluster potentially
causing a collision.
Major
Omission The satellite fails to move to its
new assigned position in the cluster
possible causing the position?
velocityIncrement and
newPositionList data to be
temporarily incorrect. This could
potentially affect other events such
as UpdateClusterInformation and
CalculateDeltaV.
The satellite will not
have moved but, rather
maintain its previous
position. Other
satellites in the cluster
may expect the satellite
to have moved to a new
position. This could
cause a collision
because of the
discrepancies between
actual and satellite
position.
Major
Cluster
Allocation
Planner
MoveNewPos
Timing/Order The satellite fails to move to the
new position until some later,
undetermined time possibly
causing its position?
velocityIncrement and
newPositionList data to may be
temporarily incorrect. This could
potentially affect other events such
as UpdateClusterInformation and
CalculateDeltaV. The satellite fails to
move to its new position at the time expected by other satellites in the cluster.
This could cause a collision.
Critical
Figure 3. An excerpt of the SFMECA of the MoveNewPos activity of the Cluster Allocation Planner role
in the TechSAT21 satellite constellation.
i.Provide the event failure mode (i.e., the keyword
used to discover possible failures).
ii.Describe the possible local effect(s) if the keyword failure happened to the event under consideration.
The local event will likely only affect this role or
this agent and its description should not include the
propagation of its failure to other agents or
components of the global system.
iii.Describe the possible system-level effect(s) if the keyword failure mode occurred. This column
captures the possible emergent hazardous behavior
from the interaction of the agents (e.g., that a
collision could occur between satellites if a satellite
does not change its position when other satellites are
expecting it to).
iv.Give the criticality (e.g., critical, major, average, etc.) of this failure as determined by the global
effect of this failure on the system as a whole.
c.Apply any additional failure modes not captured by the
provided keywords relevant to the current event and fill in the SFMECA row as appropriate. Constructing the SFMECA data table using Gaia’s Role Schema, the Permissions section lists each datum that the role can access, alter or generate. To construct a SFMECA table for the data that a role uses, we use the following keywords to guide our analysis: “incorrect value”, “absent value”, “wrong timing” and “duplicated value”. The procedure to construct a SFMECA table for the data from the Permissions section of the Role Schema is similar to that for the events’ table and is not shown here.
3.2Backward Search Safety Analysis
The backward analysis search technique used in this work utilizes a Software Fault Tree Analysis (SFTA). The SFTA can be performed in parallel and independently of the forward analysis technique(s). SFTA starts with a system hazard and traces backwards to find the contributing causes of the hypothesized root hazard. Typically, the hypothesized hazard comes from existing hazards lists or known domain hazards. If, however, the SFTA is performed following the forward analysis technique(s), each unique Possible Hazard listed in the Software Failure Modes, Effects and Criticality Analysis (SFMECA) can be used as a SFTA starting hazard. For example, it is clear from the SFMECA
for the TechSAT21 that a fault tree in the SFTA should include the hazard “satellite collision” as a root node. This is a concept of the Bi-Directional Safety Analysis (BDSA) that will be discussed further in Section 3.3.
3.3Bi-Directional Safety Analysis Results
Bi-Directional Safety Analysis (BDSA) is used to verify the completeness of the forward and backward search techniques. The forward and backward techniques can be viewed as complementary since the output of the forward technique (i.e., the potential system-wide hazards) should match-up with the inputs of the backward technique. Similarly, the output of the backward technique (i.e., the low-level, local errors that cause a system-wide hazard) should match-up with the inputs of the forward technique. For example, we can verify the completeness of the SFTA by ensuring that every unique hazard listed in the Possible Hazard column of the SFMECA table with a particular level of criticality or higher (e.g., major criticality) is a root node within one of the fault trees of the SFTA.
In our TechSAT21 example, BDSA was applied to ensure that all possible hazards labeled with a “major” or “critical” criticality level for the MoveNewPos event were captured as the root node of a fault tree. It was found that each “major” and “critical” level potential hazard in the SFMECA related to a collision of satellites and that the SFTA had already accounted for this hazard. However, comparing the event failures in the SFMECA that could possibly lead to a satellite collision with the leaf nodes of the fault trees where “satellite collision” is the root node led to the discovery that the SFTA failed to account for the possibility that a “timing/order” failure in the execution of the MoveNewPos event could be a contributing factor to a satellite collision. This omission in the SFTA is likely due to SFTA’s weakness in representing temporal/order-specific failures [15]. Thus, the BDSA not only helped in verifying that the results of the forward technique were the inputs for the backward technique and vice versa, but it also helped identify missing failure scenarios.
3.4Applying the Safety Analysis Results to Assure Safety
Bi-Directional Safety Analysis (BDSA) helped ensure that the safety analyses used for the forward and backward search techniques were consistent. In our case, the Software Failure Modes, Effects and Criticality Analysis (SFMECA) and the Software Fault Tree Analysis (SFTA) were utilized to discover further safety requirements not already specified in the Role Schema for a given role.
To assess and derive safety requirements of the Role Schema using the SFMECA, the following steps suffice:
For each Role Schema:
a.For each data/event listed in the Data/Event column of
the SFMECA for the role in the Role Schema:
i.Decide at which level of criticality (i.e., critical,
major, etc.) the role must provide mitigating
requirements to ensure safety. This may correspond
to what level of system certification is required of
the system.
ii.For each listed data/event failure mode listed in the Failure Mode column of the SFMECA with a
criticality of at least the minimum criticality level
needed for analysis (from Step i):
1.Consult the local effect of the failure mode in
the Local Effect column of the SFMECA.
Assure that the software mitigates the local
effect. For data, the mitigating requirement
could be some sanity check (i.e., checking
some other piece of data or monitoring that
the data is reasonable given the software’s
current state). For events, the mitigation
requirement could be some guard to ensure
that the event is occurring under the right
conditions and at the appropriate time given
the software’s current condition.
2.Check to make sure that the product-line
MAS software will prevent the hazard
described in the Possible Hazard column of
the SFMECA from occurring in the SFTA.
That is, check that the hazard is mitigated in
both the SFMECA and SFTA.
3.If the mitigation does not suffice to prevent
the local effect, the software may not be
compliant with system safety requirements. Applying this process on the TechSAT21 example using the partial SFMECA table, shown in Figure 3, identified several new mitigation requirements to prevent the hazard of a “satellite collision” that were then added to the Role Schema. For the “halt/abnormal termination” failure mode, the mitigation requirement was that the MoveNewPos activity be atomic (either it executes completely or not at all). Alternatively, a new NotifyFinishMoveNewPos protocol could be introduced to have the satellite notify all satellites (or the master satellite) of the completion (or non-completion) of the MoveNewPos activity. Additionally, a mitigation requirement for the “timing/order” failure mode could be to assign a timestamp deadline by which each MoveNewPos activity must complete before. Without the BDSA and SFMECA process detailed above, safety requirements such as these could be overlooked.
The use of BDSA thus assists in certification of product-line MAS in two ways:
?Demonstration of compliance. The use of BDSA provides assurances that certain classes of failure modes that might
occur in the individual agents will not produce
unacceptable effects in the composite system (e.g., the
constellation, or fleet). The artifacts produced in this
investigation (SFMECA tables, SFTAs, and the Role
Schemas responsibility statements) help demonstrate
compliance of the failure-monitoring and failure-
mitigation software tasked with the system safety
requirements.
?Enabling reuse of certification arguments. The use of product BDSA can reduce the burden of certification for
systems composed of identical or near-identical units. In
systems where each agent is a member of a product line,
the similarities can be leveraged for efficient reuse of the
safety analysis artifacts. At the same time, the use of Role
Schemas captures any variations among the roles that the
agents may assume. The Role Schemas thus help ensure
that the reuse of the artifacts in the certification arguments
accurately reflects any differences among the agents. 4.CONCLUDING REMARKS
This paper described an extension of Bi-Directional Safety Analysis (BDSA) to aid in the certification of safety-critical, product-line, multi-agent systems (MAS). This extension demonstrated a systematic process to derive a Software Failure Modes, Effects and Criticality Analysis from a product-line MAS analysis and design methodology. The safety analysis assets derived using this approach are reusable assets since they capture the behavior of the near-identical, product line members of the MAS. Using this approach, we showed how missing safety requirements can be derived from the safety analysis assets and how BDSA can assist in verifying the adequacy of the existing safety requirements and design. The resulting product-line safety assets and verification aid in efficiently assembling a safety case during system certification. Planned future work includes further investigation and evaluation of this approach on a large, product-line MAS under development.
5.ACKNOWLEDGMENTS
The authors would like to thank Qian Feng for her comments and useful discussions. This research was supported by the National Science Foundation under grants 0204139, 0205588 and 0541163.
6.REFERENCES
[1]Arkusinski, A., “A Method to Increase the Design Assurance
Level of Software by Means of FMEA,” Proc. 24th Digital
Avionics Systems Conference, 2:10.D.5-1-10.D.5-11, 2005.
[2]Bresciani, P., Giorgini, P., Guinchiglia, F., and Perini, A.,
“TROPOS: An Agent-Oriented Software Development
Methodology,” Journal of Autonomous Agents and Multi-
Agent Systems, 8(1):203-236, 2004.
[3]Chien, S. et al., "The Techsat-21 Autonomous Space Science
Agent", Proc. 1st International Conference on Autonomous
Agents, pp. 570-577, 2002.
[4]Chien, S., Sherwood, R., Tran, D., et. al., “Lessons Learned
from Autonomous Sciencecraft Experiment,” Proc.
Autonomous Agents and Multi-Agent Systems Conference,
2005.
[5]Clements, P., Software Product Lines, Addison-Wesley,
Reading, MA, 2002.
[6]Dehlinger, J. and Lutz, R. R., "A Product-Line Approach to
Promote Asset Reuse in Multi-Agent Systems," Software for Multi-Agent Systems IV, Lecture Notes in Computer Science, to appear, 2006.
[7]Dehlinger, J. and Lutz, R. R., "A Product-Line Requirements
Approach to Safe Reuse in Multi-Agent Systems," Proc.
ICSE 2005 Workshop on Software Engineering for Large
Multi-Agent Systems, pp. 83-89, 2005.
[8]Dehlinger, J. and Lutz, R. R., "PLFaultCAT: A Product-Line
Software Fault Tree Analysis Tool," The Automated
Software Engineering Journal, 13(1):169-193, 2006. [9]DeLoach, S. A., “The MaSE Methodology,” Methodologies
and Software Engineering for Agent Systems – The Agent-
Oriented Software Engineering Handbook Series: Multi-
Agent Systems, Artificial Societies, and Simulated
Organizations, 11:107-125, 2004.
[10]Despotou, G. and Kelly, T., “Extending the Safety Case
Concept to Address Dependability,” Proc. 22nd Int’l System Safety Conference, pp.645-654, 2004.
[11]European Cooperation for Space Standardization (ECSS),
Space Engineering – Software, ECSS-E-40B (draft 1), 2002.
[12]Feng, Q. and Lutz, R. R., "Bi-Directional Safety Analysis of
Product Lines," Journal of Systems and Software, 78(2):111-127, 2005.
[13]Hollow, P. McDermid, J. and Nicholson, M., “Approaches to
Certification of Reconfigurable IMA Systems,” Proc. 5th
Int’l Symposium of the Int’l Council on Systems Engineering, 2000.
[14]Lamport, L. and Lynch, N., “Distributed Computing Models
and Methods,” Formal Models and Semantics, Vol. B,
Handbook of Theoretical Computer Science, Elsevier, 1990.
[15]Leveson, N. G., Safeware: System Safety and Computers,
Addison-Wesley, Reading, MA, 1995.
[16]Lutz, R. R. and Woodhouse, R. M., ‘Bi-Directional Analysis
for Certification of Safety Critical Software,” Proc. 1st
International Software Assurance Certification Conference, 1999.
[17]Lutz, R. R. and Woodhouse, R. M., “Requirements Analysis
Using Forward and Backward Search,” Annals of Software
Engineering, 3(1):459-475, 1997.
[18]“NASA Strategic Roadmaps,” NASA – APIO: Strategic
Roadmaps - Overview, https://www.doczj.com/doc/af5395509.html,/about/strategic _roadmaps.html, (current February 2006).
[19]Radio Technical Commission for Aeronautics, RTCA/DO-
178B: Software Considerations in Airborne Systems and
Equipment Certification, 1992.
[20]SAE, Aerospace Recommended Practice: Guidelines and
Methods for Conducting the Safety Assessment Process on
Civil Airborne Systems and Equipment, ARP4761, 1996. [21]Schetter, T., Campbell, M. and Surka, D., "Multiple Agent-
Based Autonomy for Satellite Constellations," Proc. 2nd
International Symposium on Agent Systems and
Applications, 2000.
[22]“Terrestrial Planet Finder Project,” Planet Quest: Missions –
Terrestrial Planet Finder,
https://www.doczj.com/doc/af5395509.html,/TPF/ tpf_index.html, (current February 2006).
[23]Weiss, D. M. and Lai, C. T. R. Software Product-Line
Engineering, Addison-Wesley, Reading, MA, 1999. [24]Zambonelli, F., Jennings, N. R. and Woolridge, M.,
“Developing Multiagent Systems: The Gaia Methodology”, ACM Transactions on Software Engineering and
Methodology, 12(3):317-370, 2003.
安装、使用产品前，请阅读安装使用说明书。 请妥善保管好本手册，以便日后能随时查阅。 GST-DJ6000系列可视对讲系统 液晶室外主机 安装使用说明书 目录 一、概述 (1) 二、特点 (2) 三、技术特性 (3) 四、结构特征与工作原理 (3) 五、安装与调试 (5) 六、使用及操作 (10) 七、故障分析与排除 (16) 海湾安全技术有限公司
一概述 GST-DJ6000可视对讲系统是海湾公司开发的集对讲、监视、锁控、呼救、报警等功能于一体的新一代可视对讲产品。产品造型美观，系统配置灵活，是一套技术先进、功能齐全的可视对讲系统。 GST-DJ6100系列液晶室外主机是一置于单元门口的可视对讲设备。本系列产品具有呼叫住户、呼叫管理中心、密码开单元门、刷卡开门和刷卡巡更等功能，并支持胁迫报警。当同一单元具有多个入口时，使用室外主机可以实现多出入口可视对讲模式。 GST-DJ6100系列液晶室外主机分两类（以下简称室外主机），十二种型号产品： 1.1黑白可视室外主机 a)GST-DJ6116可视室外主机（黑白）； b)GST-DJ6118可视室外主机（黑白）； c)GST-DJ6116I IC卡可视室外主机（黑白）； d)GST-DJ6118I IC卡可视室外主机（黑白）； e)GST-DJ6116I（MIFARE）IC卡可视室外主机（黑白）； f)GST-DJ6118I（MIFARE）IC卡可视室外主机（黑白）。 1.2彩色可视液晶室外主机 g)GST-DJ6116C可视室外主机（彩色）； h)GST-DJ6118C可视室外主机（彩色）； i)GST-DJ6116CI IC卡可视室外主机（彩色）； j)GST-DJ6118CI IC卡可视室外主机（彩色）； k)GST-DJ6116CI（MIFARE）IC卡可视室外主机（彩色）； GST-DJ6118CI（MIFARE）IC卡可视室外主机（彩色）。 二特点 2.1 4*4数码式按键，可以实现在1~8999间根据需求选择任意合适的数字来 对室内分机进行地址编码。 2.2每个室外主机通过层间分配器可以挂接最多2500台室内分机。 2.3支持两种密码（住户密码、公用密码）开锁，便于用户使用和管理。 2．4每户可以设置一个住户开门密码。 2.5采用128×64大屏幕液晶屏显示，可显示汉字操作提示。 2.6支持胁迫报警，住户在开门时输入胁迫密码可以产生胁迫报警。 2.7具有防拆报警功能。 2.8支持单元多门系统，每个单元可支持1～9个室外主机。 2.9密码保护功能。当使用者使用密码开门，三次尝试不对时，呼叫管理中 心。 2.10在线设置室外主机和室内分机地址，方便工程调试。 2.11室外主机内置红外线摄像头及红外补光装置，对外界光照要求低。彩色 室外主机需增加可见光照明才能得到好的夜间补偿。 2.12带IC卡室外主机支持住户卡、巡更卡、管理员卡的分类管理，可执行 刷卡开门或刷卡巡更的操作，最多可以管理900张卡片。卡片可以在本机进行注册或删除，也可以通过上位计算机进行主责或删除。
目录 第1章概述 (1) 1.1 技术开发部管理权限 (1) 1.2 技术开发部管理职能 (1) 1.3 技术开发部主要职责 (1) 1.4 日常管理制度 (2) 第2章产品开发设计控制程序 (4) 2.1 目的 (4) 2.2 范围 (5) 2.3 引用文件及术语 (5) 2.4 职责 (5) 2.5 工作程序 (6) 2.6 支持文件 (9) 2.7 表格清单 (9) 2.8 附表 (9) 第3章产品实现的策划程序 (17) 3.1 目的 (17) 3.2 适应范围 (17) 3.3 引用文件及术语 (18) 3.4 职责 (18) 3.5 工作程序 (18) 3.6 支持性文件 (19) 第4章内部质量审核控制程序 (20) 4.1 目的 (20) 4.2 适用范围 (20) 4.3 引用文件及术语 (20) 4.4 职责 (20) 4.5 工作程序 (21) 4.6 支持文件 (23) 4.7 质量记录 (23) 附录 (25) 附录1 (25) 附录2 (26) 附录3 (27) 附录5 (29) 附录6 (30) 附件7 (31) 附件8 (32)
第1章概述 技术开发部的工作主要是从事电表、水表、煤气表及其远程自动抄系统的研发和产品的优化，以及为生产部和工程部提供技术支持等。 1.1 技术开发部管理权限 受总经理和技术总监委托，行使对公司技术引进、新产品开发研究、新技术推广应用、技术指导与监督等全过程听管理权限，并承担执行公司规章制度、管理规程及工作指令的义务； 1.2 技术开发部管理职能 负责对公司产品实行技术指导、规范工艺流程、制定技术标准、抓好技术管理、实施技术监督和协调的专职管理部门，对所承担的工作负责。 1.3 技术开发部主要职责： 1．坚决服从总经理和技术总监的统一指挥，认真执行其工作指令，一切管理行为向总经理和技术总监负责； 2．严格遵守公司规章制度，认真履行其工作职责； 3．负责制定公司技术管理制度。负责建立和完善产品设计、新产品的试制、标准化技术规程、技术情报管理制度，组织、协调、督促有关部门建立和完善设备、质量、能源等管理标准及制度； 4．组织和编制公司技术发展规划。编制近期技术提高工作计划，编制长远技术发展和技术措施规划，并组织对计划、规划的拟定、修改、补充、实施等一系列技术组织和管理工作； 5．负责制订和修改技术规程。编制产品的使用、维修和技术安全等有关的技术规定； 6．负责公司新技术引进和产品开发工作的计划、实施，确保产品品种不断更新和扩大； 7．合理编制技术文件，改进和规范工艺流程； 8．研究和摸索科学的流水作业规律，认真做好各类技术信息和资料收集、整理、分析、研究汇总、归档保管工作，为逐步实现公司现代化销售的目标，提供可靠的指导依据； 9．负责制定公司产品的企业统一标准，实现产品的规范化管理； 10．编制公司产品标准，按年度审核、补充、修订定额内容；
F6门禁管理系统用户手册 目录 1.系统软件 (2) 2.服务器连接 (2) 3.系统管理 (3) 3.1系统登录 (3) 3.2修改密码 (3) 4.联机通讯 (4) 4.1读取记录 (4) 4.2自动下载数据 (5) 4.3手动下载数据 (5) 4.4实时通讯 (6) 4.5主控设置 (6) 5.辅助管理 (8) 5.1服务器设置 (8) 5.2系统功能设置 (9) 5.3读写器设置 (10) 5.4电子地图 (13) 6.查询报表 (14) 6.1开锁查询 (14) 7.帮助 (18) 7.1帮助 (18)
1.系统软件 图1 门禁管理软件主界面 F6版门禁管理系统的软件界面如上图，顶端菜单栏包括“系统管理”、“联机通讯”、“辅助管理”、“查询报表”和“帮助”菜单；左侧快捷按钮包括“系统管理”、“联机通讯”、“辅助管理”、“查询报表”、“状态”等主功能项，每个主功能项包含几个子功能，在主界面上可以不依靠主菜单，就可在主界面中找到每个功能的快捷按钮。以下按照菜单栏的顺序进行介绍。 2.服务器连接 如图2点击设置则进入远程服务器设置，此处的远程服务器IP地址不是指数据库服务器，而是指中间层Fujica Server服务管理器的IP地址。 图2 服务连接
图2 远程服务器设置 3.系统管理 3.1系统登录 系统默认的操作员卡号为“0001”，密码为“admin”，上班人员输入管理卡号和密码后可以进入系统，进行授权给他的一切操作。 图3 系统登录 3.2修改密码 修改密码是指操作员登录成功后，可以修改自己登录的密码。先输入操作员的旧密码，再输入新密码并确认，则密码修改成功。
浙江吉利控股集团有限公司企业标准
浙江吉利控股集团有限公司 新产品质量管理手册 （第1版）V1.0 浙江吉利控股集团有限公司 2011-11-25发布 2011-12-30实施
说明 为贯彻集团“两个转型”和“两个调整”的经营工作思路，实现从“产品线管理”向“品牌线管理”的调整，规范和细化集团新产品项目质量管理过程，明确质量系统各单位在新产品质量管理过程中的职责及工作内容，使实际工作开展有规可循，并强化可操作性，特制定此《吉利集团新产品质量管理手册》（第1版）,版本号为V1.0。
目录 第一章新产品质量管理总则 第二章新产品质量评审流程 第三章新产品品熟推进流程 第四章附录
第一章 新产品质量管理总则 1.1目的 为了规范集团新产品开发各阶段的质量管理，促进各部门在新品阶段的质量自主管理能力，并以用户满意为最终目标，展开各阶层新产品质量管理。 1.2范围 本手册适用于以下项目范围：整车开发项目，发动机开发项目，变速器开发项目等各类将以量产形式生产并销售的新产品正式立项开发项目（具体项目分类界定规则参照《研发项目管理办法 V2.1》，涉及具体工作开展项目范围时，可由关联单位协商界定）。 1.3新产品质量管理模式 集团新产品质量管理采用由集团质量管理部建立统一的管理体系，各品牌质量部主导策划管控及实施，各系统分级管控的模式。通过前期的弱点项目（雷区项目）设计输入、依托各新产品项目品熟团队，以不断循环展开的阶段质量阀评审以及品熟活动，达成新产品质量保证，最终实现用户满意。新产品质量管理对新产品整体项目质量负责，确保新产品项目质量达标，满足设计和市场要求。新产品质量管理绩效评价按集团质量部相关考核指标展开（参看集团质量体系考核相关文件）。 1.3.1新产品质量管控过程 新产品质量管理涉及集团项目管理流程全部三个阶段： 1.3.1.1立项阶段的质量管控 在新产品立项阶段，质量部门负责项目质量策划，并向项目组输出项目各阶段项目质量目标、《质量目标保障计划书》，以及过往和在产产品设计相关弱点问题清单（雷区项目），全部内容均可包含在《质量目标保障计划书》中一并提交。 1.3.1.1.1 新产品质量目标的策划（包括各开发试制阶段及量产阶段） ·质量目标设定的原则： -新产品质量目标的设定应与集团的经营战略相一致； -新产品的质量目标应根据车型平台特征、市场分析、过往质量水平进行各阶段的目标设定（数据来源包括设计、采购、制造、市场等各产品过程相关部门），并在各阶段质量评审中进行考评； -质量目标应包括反映设计改善、制造、市场、供应商品质等各领域产品及过程相关的指标内容，具体可根据项目实际进行增加或删减。基础项目请参考《第四章 附录》中的《质量目标基础项目表》。 目标设定后应向各质量责任单元分解，并制定相应的质量目标保障措施。 立项阶段 实施与控制阶段 关闭阶段
ID一体式/嵌入式门禁管理系统 使用说明书
1 软件使用说明 （1）配置要求 在安装软件之前，请先了解您所使用的管理电脑的配置情况。本软件要求安装在（基本配置）： Windows 2000，windows xp操作系统； 奔腾II600或更高的处理器(CPU)； 10GB以上硬盘； 128MB或更大的内存； 支持分辨率800*600或更高的显示器。 （2）安装说明 在光盘中运行“智能一卡通管理系统”安装程序（ID版），按照安装提示依次操作即可。 安装数据库以后，有两种创建数据库的方式，手动创建和自动创建。手动创建：在数据库SQL Server2000的数据库企业管理器中，建立一个database(数据库)。进入查询分析器/Query Analyzer 运行智能一卡通管理系统的脚本文件，形成门禁数据库表；自动创建：在安装智能一卡通管理软件中自动创建默认门禁数据库，默然数据名：znykt。 上述安装完后，在安装目录下,在first.dsn 文件中设置其参数，计算机server的名字（无服务器时即本机名）和数据库database的名字。 在桌面运行智能一卡通管理系统运行文件，选择卡号888888，密码为123456即可进入系统。 2 人事管理子系统 部门资料设置 首先运行‘智能一卡通管理系统’软件后，进入软件主界面，如下图所示：
然后点击进入“人事管理子系统”，如图所示： 选择<人事管理>菜单下的<部门管理>或点击工具栏内的‘部门管理’按钮，则会出现如下所示界面： 在<部门管理>中可以完成单位内部各个部门及其下属部门的设置。如果公司要成立新的部门，先用鼠标左键单击最上面的部门名，然后按鼠标右键弹出一菜单，在菜单中选择“增加部门”，则光标停留在窗口右边的“部门编号”输入框中，在此输入由用户自己定义的部门编号后，再在“部门名称”输入框中输入部门名称，最后按 <保存>按钮，此时发现窗口左边的结构图中多了一个新增的部门。如果要给部门设置其下属部门，则首选用鼠标左键选中该部门，再按鼠标右键弹出一菜单，在菜单中选择“增加”，最后输入、保存。同时也可以对选中的部门或下属部门进行“修改”或“删除”。特别要注意的是，如果是“删除”,则被选中的部门及其下属部门将被全部删除，所以要特别谨慎。
新产品开发项目管理制度 1.目的和作用 新产品开发是企业在激烈的技术竞争中赖以生存和发展的命脉,它对企业产品发展方向、产品优势、开拓新市场、提高经济效益等方面起着决定性作用。为了使新产品开发能够严格遵循科学管理程序进行，取得较好的效果，特制定本制度。 2.管理职责 2.1统筹规划部负责新产品的调研分析与立项等方面的工作。 2.2技术研发部负责产品的设计、试制、鉴定、移交投产等方面的管理。 2.3物控部、生产部、质管部应在整个开发过程中给予支持和配合。 3.新产品开发的前期调研分析工作 新产品的可行性分析是新产品开发不可缺少的前期工作,必须在进行充分的技术和市场调查后,对产品的社会需要、市场占有率、技术现状、发展趋势以及资源效益等五个方面进行科学预测及经济性的分析论证。 3.1 调查研究: 3.1.1 调查国内市场和重要用户以及国际重点市场的技术现状和改进要求. 3.1.2 以国内同类产品市场占有率高的前三名以及国际名牌产品为对象,调查同类产品的质量、价格及使用情况。
3.1.3 广泛收集国内外有关情报和专利,然后进行可行性分析研究. 3.2 可行性分析: 3.2.1 论证该产品的技术发展方向和动向. 3.2.2 论证市场动态及发展该产品具备的技术优势. 3.2.3 论证该产品发展所具备的资源条件和可行性(含物资、设备、能源、外购外协配套等）。 3.2.4 初步论证技术经济效益。 3.2.5 写出该产品批量投产的可行性分析报告。 4. 产品设计管理 产品设计时从确定产品设计任务书起到确定产品结构为止的一系 列技术工作的准备和管理,是产品开发的重要环节,必须严格遵循"三 段设计"程序. 4.1 技术任务书: 技术任务书市产品在初步设计阶段内,由设计部门向上级提出的 体现产品合理设计方案的改进性和推存性意见的文件,经上级批准后,作为产品技术设计的依据.其目的在于正确地确定产品的最佳总体设计方案、主要技术性能参数、工作原理、系统和主体结构，并由设计员负责编写（其中标准化规则要求会同标准化人员共同拟定）。现对其编写内容和程序作如下规定： 4.1.1 设计依据(根据具体情况可以包括一个或数个内容): a. 国内外技术情报:在市场的性能和使用性方面赶超国内外先进水平,或在产品品种方面填补国内"空白".
《门禁系统使用说明书》
陕西********科技有限公司 单位地址：**************************** 联系电话：**************************** 目录 （ 1.1）软件系统---------------------------------------------------------------------------------------1-135 第一章软件基本操作...................................................................................................................... - 5 - 2.1进入操作软件 (5) 2.4人事管理 (7) 2.4.1 企业信息.................................................................................................................................................................. - 7 - 2.4.2添加/编辑部门信息 ................................................................................................................................................ - 9 - 2.4.2.1添加部门 ............................................................................................................................................................... - 9 - 2.4.2.2修改部门 ............................................................................................................................................................ - 10 - 2.4.2.3 删除部门 ........................................................................................................................................................... - 11 -
新产品开发管理制度 新产品开发工作，是指运用国内外在基础研究与应用研究中所发现的科学知识及其成果，转变为新产品、新材料、新生产过程等一切非常规性质的技术工作。新产品开发是企业在激烈的技术竞争中赖以生存和发展的命脉，是实现“生产一代，试制一代，研究一代和构思一代”的产品升级换代宗旨的重要阶段，它对企业产品发展方向，产品优势，开拓新市场，提高经济效益等方面起着决定性的作用。因此，新产品开发必须严格遵循产品开发的科学管理程序，即选题(构思、调研和方案论证)_样(模)试_批试_正式投产前的准备这些骤。 新产品的可行性分析是新产品开发中不可缺少的前期工作，必须在进行充分的技术和市场调查后，对产品的社会需求、市场占有率、技术现状和发展趋势以及资源效益等五个方面进行科学预测及技术经济的分析论证。 (一)调查研究： 1.调查国内市场和重要用户以及国际重点市场同类产品的技术现状和改进要求； 2.以国内同类产品市场占有率高的前三名以及国际名牌产品为对象，调查同类产品的质量、价格、市场及使用情况； 3.广泛收集国内外有关情报和专刊，然后进行可行性分析研究。 (二)可行性分析： 1.论证该类产品的技术发展方向和动向。 2.论证市场动态及发展该产品具备的技术优势。 3.论证发展该产品的资源条件的可行性。(含物资、设备、能源及外购外协件配套等)。 (三)决策： 1.制定产品发展规划： (1)企业根据国家和地方经济发展的需要、从企业产品发展方向、发展规模，发展水平和技术改造方向、赶超目标以及企业现有条件进行综合调查研究和可行性分析，制定企业产品发展规划。 (2)由研究所提出草拟规划，经厂总师办初步审查，由总工程师组织有关部门人员进行慎密 的研究定稿后，报厂长批准，由计划科下达执行。 2.瞄准世界先进水平和赶超目标，为提高产品质量进行新技术、新材料、新工艺、新装备方面的应用研究： (1)开展产品寿命周期的研究，促进产品的升级换代，预测企业的盈亏和生存，为企业提供产品发展的科学依据； (2)开展哪些对产品升级换代有决定意义的科学研究、基础件攻关、重大工艺改革、重大专用设备和测试仪器的研究； (3)开展哪些对提高产品质量有重大影响的新材料研究； (4)科研规划由研究所提出草拟规划交总师办组织有关部门会审，经总工程师签字报厂长批准后，由计划科综合下达。
-- - XX职业技术学院信息工程学院 门禁管理系统 操作说明书
制作人：X珍海 日期：2014年3月25日 目录 (请打开【帮助H】下的【使用说明书】，这样方便您了解本系统) 第1章软件的基本操作3 1.1 登录和进入操作软件3 1.2 设备参数设置4 1.3 部门和注册卡用户操作4 1.3.1 设置部门4 1.3.2 自动添加注册卡功能（自动发卡）5 1.4 基本操作7 1.4.1 权限管理8 1.4.2 校准系统时间11 1.5 常用工具12 1.5.1 修改登陆用户名和密码12 第2章考勤管理功能模块13 2.1 正常班考勤设置13 2.1.1 设置考勤基本规则13 2.1.2 设置节假日和周休日14 2.1.3 请假出差的设置15 2.2 考勤统计和生成报表17 2.2.1 生成考勤详细报表17 2.2.2 启用远程开门错误!未定义书签。
第1章软件的基本操作 1.1登录和进入操作软件 1．点击【开始】>【程序】>【专业智能门禁管理系统】>【专业智能门禁管理系统】或双击桌面钥匙图标的快捷方式，进入登录界面。 2．输入缺省的用户名：abc 与密码：123（注意：用户名用小写）。该用户名和密码可在软件里更改。 3．登录后显示主操作界面
入门指南。如果您没有经验，您可以在该向导的指引下完成基本的操作和设置。我们建议您熟悉后, 关闭操作入门指南，仔细阅读说明书，熟悉和掌握软件的操作。 “关闭入门指南”后，操作界面如下。 1.2设备参数设置 1.3部门和注册卡用户操作 1.3.1设置部门 点击【设置】>【部门】，进入部门界面。 点击【添加最高级部门】。
新产品开发与管理手册 主办:上海普瑞思管理咨询有限公司 2010年１１月29—30日北京11月25—时间： 2０10年10月28—２９日深圳 10月25—26日杭州? ２6日上海 ２010年12月3０—31日北京１2月2７—２８日深圳 价格：￥2２00 /人(包括授课费、资料费、会务费、证书、午餐等) 【培训对象】企业CEＯ／总经理、研发总经理/副总,公司总工/技术总监,公司人力资源总监、产品线总监、产品经理/项目经理、PＭO(项目管理办公室)成员、市场总监、技术支持总监等。 【课程背景】 2008年一场金融风暴席卷全球,大量的工业企业倒闭关门，大批员工失业。在这场金融危机中我们发现还是有很多企业不但没有倒下,反而更加高速成长,其中一个重要的原因就是这些企业构建了成功的产品管理体系,培养了优秀的产品经理，能够组织团队开发出具有竞争力、满足客户需求的产品。公司在冬天更应该加强自己内功的修炼来应对危机，同时迎接春天的到来。 当一个企业从单一产品线向多产品线跨越的时候,必须突破的一个瓶颈就是公司产品经理的培养，因为产品经理是公司价值链中最重要的一个环节，是直接面向客户、带领团队创造价值的领军人物，因此产品经理个人及其所率领的团队的能力往往决定了该产品在市场上的竞争力。业界大量公司在构建产品管理体系和培养产品经理的过程中常见如下困惑的问题： 1.产品经理该如何定位?究竟定位于研发还是定位于市场？ 2.产品经理和项目经理有什么区别?如何作好分工??３.产品经理究竟应该具有什么样的素质模型?谁来承担 比较合适? 4.产品经理如何参与产品的市场管理流程？如何从源头来规划产品??５.如何推动产品开发全流程的工作??6.如何协调产品的市场管理、开发管理、财经管理之间的关系？ 7.产品经理如何管理产品团队? ８.公司如何建立产品经理的培养体系以成批培养产品经理？ 本课程在过去４年讲授的基础上作了大量的更新，结合业界成功公司在产品经理培养和管理上的一些教训和经验，针对以上难题进行深入的讲解，并总结出如何建立公司的产品经理资源池来批量培养成功的产品经理，实现公司规模化的扩张。 ?≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡ 【课程收益】 1.分享讲师数百场研发管理培训的专业经验，通过现场的互动帮助学员理清适合自己企业的产品管理的思路和产品经理的培养方案 2．分析业界公司在产品经理培养和管理中的误区，并分享成功经验?3.了解产品经理的定位、职责、素质模型与任职资格标准 4.理解新产品市场管理、路标规划、需求管理的流程及支撑体系 5.掌握新产品开发的过程管理的技巧和方法? 6.掌握新产品上市管理的技巧和方法，总结保证产品商业成功的关键? 7.学会如何打造一个成功的产品团队，如何管理产品团队的绩效和冲突处理 8.学会如何建立产品经理的培养体系――资源池
新产品研发管理制度第一条目的和作用 1.1 新产品研发是企业在激烈的市场竞争中赖以生存和发展的创新活动，对 企业产品发展方向、巩固产品优势、开拓新市场、提高经济效益等方面起着决 定性作用。为了使新产品开发能够严格遵循科学管理程序进行，取得较好的效果，特制定本制度。 1.2 本制度中所指的新产品的研发包括新产品开发和产品的持续改进。 第二条管理职责 2.1 技术中心负责新产品的市场调研分析、立项、设计、开发、验证、试制、移交投产等工作。 2.2 生产部、质检部、销售部（含外贸部）、供应部等部门应在新产品研发 过程中给予支持和配合。 第三条新产品研发的前期调研分析工作 新产品的可行性分析是新产品研发不可缺少的前期工作，必须在进行充分的 技术和市场调研后，对产品的社会需要、市场占有率、技术现状、发展趋势以及资源效益等多方面进行综合的科学预测及经济性的分析论证。 3.1 调查研究 3.1.1 调查国内市场和重要用户以及国际重点市场的技术现状和改进要 求。 3.1.2 以国内同类产品市场占有率高的前三名以及国际同类名牌产品为对 象，调查同类产品的质量、价格、市场及使用等情况。 3.1.3 广泛收集国内外有关情报和专利，然后进行可行性分析研究。 3.2 可行性分析
3.2.1 论证拟新发产品的技术发展方向和动向。 3.2.2 论证拟新研发产品的市场动态及发展该产品具备的技术优势。 3.2.3 论证拟新研发产品发展所具备的资源条件和可行性（含物资、设备、 能源、外购外协配套设施等）。 3.2.4 初步论证拟新研发产品的技术经济效益和社会效益。 第四条新产品研发管理 4.1 研发项目的立项与实施研发 4.1.1 技术中心填报《 XXX项目建议书》（见附件1），上报公司批准后，确定立项。技术中心下达《设计开发任务书》（见附件2）给研发项目负责人。 4.1.2 研发项目负责人根据《设计开发任务书》编制《设计开发方案》（详见附件 3）和《设计开发计划书》（详见附件 4），并组织项目小组进行新产品研发工作。 4.2 研发过程的管理与控制 4.2.1 研发项目负责人根据研发项目进度，在小试、中试阶段提出评审需 求，由技术中心组织人员进行评审，并出具《设计开发评审报告》（详见附件 5）。 4.2.2 研发项目负责人根据《设计开发评审报告》组织项目组对项目进行 改进、继续开发，至试产，填报《试产总结报告》报技术中心和公司审核。确定 投入大批量生产的，报公司总经理批准。 4.2.3 技术文件资料的验收及存档。技术中心负责将全部文件收齐归档， 资料管理人员存档时必须验证齐全。 4.3 知识产权登记与管理 在不泄露公司技术秘密的前提下，公司认为有必要申请国家知识产权的研发技术或产品，有研发项目组负责提供相关的技术资料和文件，技术中心只是产权管理人员负责相关申请报批工作。
门禁系统管理平台详细设计报告 2015年09月20日
目录 一、基本信息 .................................................................................................................. 错误！未定义书签。 二、市场分析 (4) 1．客户需求分析 (4) （1）国际国内市场需求量预测及客户咨询类似产品情况..... 错误！未定义书签。 （2）客户对该产品的功能、安全、使用环境要求等............. 错误！未定义书签。 2．市场现状分析 (4) 三、详细设计 (4) 1. 模块描述 (4) 2. 功能描述 (4) 3. 信息传输过程 (6) 4. 标准符合性分析 (6) 5. 验证（试制/试验/检测）确认方法、手段的分析 (8) 四、资源论证 (8) 1．人力资源需求分析 (8) 2．开发设备资源需求分析 (9) 3．项目开发成本预算 (9) 五、研发时间安排 (9) 六、项目风险评估 (10) 1．技术方面 (10) 2．人员方面 (10) 3．其它资源 (10) 七、评审结论 (11) 八、公司意见 (11)
一、市场分析 1．客户需求分析 1.2014年7月份由三大运营商出资成立了中国通信设施服务股份有限公司，同年9月份 变更名称为中国铁塔股份有限公司。铁塔公司成立后，2015年12月下旬，2000多亿存量铁塔资产基本完成交接。而从2015年1月1日起，三大运营商停止新建铁塔基站，交由中国铁塔进行建设。据统计，2015年1-11月，中国铁塔累计承接三家电信运营企业塔类建设需求53.2万座，已交付41.8万座。针对如此庞大的存量基站及新建基站。 铁塔公司总部急需对基站人员进出做到统一管理，有效管控。提高效率。因此所产生的市场需求量是很大的。 2.随着互联网及物联网技术的快速发展，原有传统门禁管理系统、单一功能的管理软件已 经无法管理众多不同品牌、不同通讯方式、不同厂家的IC/ID读卡设备，因此客户需要一种开放式、分布式的云管理平台，来管理整个基站门禁系统中的所有设备 2．市场现状分析 ●同行业中，各厂家的产品采用传统的门禁方案，既读卡器和控制器及电磁锁或电插锁对 现场的基站门进行管理。造价昂贵，安装复杂。。 ●目前大部分厂家的管理平台架构单一，系统兼容性差，各家的门禁管理平台只能兼容自 家的控制器。开放性不够。 ●目前很多厂商的平台都是针对某一个硬件厂商的设备来运行的，当项目中有多家设备时 平台的控制力明显不足 二、详细设计 1. 模块描述 铁塔基站门禁系统管理平台系统主要包括三部分：BS/CS客户端、云服务器和手机APP。 其中客户端的主要功能包括： 支持对多家基站锁具设备的识别、获取、登录 支持对不同用户进行权限划分。 支持对锁具根据区域进行分组。 支持多家基站锁具设备的设备配置 支持多家设备通过手机APP开锁、获取状态、日志查询。 支持多家设备的设备时间校准 支持设备更新，当设备更新时，可以方便的只更新涉及到的文件，而不需要重装整个系统 支持电子地图
新产品开发和上市管理制度 1目的 对新产品开发和上市的全过程进行控制，确保产品能满足顾客的需求和期望及符合有关法律、法规要求。 2范围 适用于本公司新产品的开发与上市管理。 3职责 3.1 市场部负责项目的立项归口管理。 3.2 总经理负责批准项目立项。 3.3 研发中心负责新产品配方设计、试验评价、技术标准的组织管理工作。 3.4 财务部负责成本核算。 3.5 生产部及品控部参与新产品加工工艺及生产条件的确认、试生产活动。 销管部负责收集顾客使用新产品后的意见或建议并反馈信息。 4内容 4.1项目的立项确认 市场部根据本部门对市场的调研和了解，以《产品开发项目立项书(讨论稿)》的形式提出立项建议，组织相关部门召开专题会对立项书内容进行讨论，并将讨论的结果进行分析整理，形成正式的《产品
开发项目立项书》后报总经理审批。 4.2 开发计划书的确认 立项确认后，市场部组织相关部门讨论确定开发计划，根据讨论结果完成《产品设计开发计划书》，下发各相关部门，各部门根据推进计划中的时间安排制定本部的工作计划。在项目推进过程中，市场部将在必要时向相关部门通报项目进展情况，如有特殊情况，市场部将以专题会议或书面形式通知各相关部门。 4.3开发计划的实施 4.3.1产品小试阶段 a.研发中心通过技术资料的搜集，设计新产品的试验方案，试验方案包括：试验配方、工艺过程等内容。 b.新产品使用的原辅料原则上以公司现有的原辅料优先选择，若为公司内部没有的原辅料，可联系厂家索取样品。必要时可请采购部协助解决。 c.新产品经过反复试验和改进后，可将认为满意的产品在研发中心内部进行品尝。品尝通过后，组织公司内部品尝并填写《产品综合品评表》和《样品品评结果处置表》。 d.公司内部品尝前，应依据新产品不同的特点，设定相应的通过标准，超过评定标准时，则视为新产品小试通过。如内部品尝未能通过，则应对新产品继续进行试验和改进。 e.小试产品品评通过后方可进行中试申请。 4.3.2中试阶段
IC一体式/嵌入式门禁管理系统 使用说明书
目录 1．系统简介 (3) 2．功能特点 (3) 3、主要技术参数 (4) 4、系统组成 (4) 5、设备连接 (5) 6、门禁管理系统软件 (6) 6.1 软件的安装 (6) 6.2 人事管理子系统 (7) 6.3 一卡通管理系统 (9) 6.4 门禁管理子系统 (12) 7. 调试操作流程 (28) 8、注意事项 (28)
1．系统简介 在高科技发展的今天，以铁锁和钥匙为代表的传统房门管理方式已经不能满足要求，而集信息管理、计算机控制、Mifare 1 IC智能(射频)卡技术于一体的智能门禁管理系统引领我们走进新的科技生活。 Mifare 1 IC智能(射频)卡上具有先进的数据通信加密并双向验证密码系统，卡片制造时具有唯一的卡片系列号，保证每张卡片都不相同。每个扇区可有多种密码管理方式。卡片上的数据读写可超过10万次以上；数据保存期可达10年以上，且卡片抗静电保护能力达2KV以上。具有良好的安全性，保密性，耐用性。 IC卡嵌入式门禁管理系统以IC卡作为信息载体，利用控制系统对IC卡中的信息作出判断，并给电磁门锁发送控制信号以控制房门的开启。同时将读卡时间和所使用的IC卡的卡号等信息记录、存储在相应的数据库中，方便管理人员随时查询进出记录，为房门的安全管理工作提供了强有力的保证。 IC卡嵌入式门禁管理系统在发行IC卡的过程中对不同人员的进出权限进行限制，在使用卡开门时门禁控制机记录读卡信息，在管理计算机中具有查询、统计和输出报表功能，既方便授权人员的自由出入和管理，又杜绝了外来人员的随意进出，提高了安全防范能力。 IC卡嵌入式门禁管理系统，在线监控IC卡开门信息、门状态，给客户以直观的门锁管理信息。 IC卡嵌入式门禁（简称门禁读卡器，门禁控制机，控制器）是目前同行业产品中体积较小的门禁，可以嵌入到市场上几乎所有的楼宇门禁控制器中，解决了因为楼宇门禁控制器内部空间小所带来的麻烦，是楼宇门禁控制器的最佳配套产品；它绝不仅仅是简单的门锁工具，而是一种快捷方便、安全可靠、一劳永逸的多功能、高效率、高档次的管理系统。它能够让你实实在在享受高科技带来的诸多实惠和方便。 2．功能特点 2．1．IC卡嵌入式门禁具有的功能： 2.1.1使用MIFARE 1 IC卡代替钥匙，开门快捷，安全方便。 2.1.2经过授权，一张IC卡可以开启多个门（255个以内）。 2.1.3可以随时更改、取消有关人员的开门权限。 2.1.4读卡过程多重确认，密钥算法，IC卡不可复制，安全可靠。 2.1.5具有512条黑名单。
8.3.产品和服务的设计和开发 8.3.1.总则 公司产品和服务的设计和开发由技术质保部归口管理，设计和开发活动应明确设计和开发的目的，公司制定和实施《产品和服务的设计和开发控制程序》，对设计和开发的策划、输入、过程控制、输出及更改做出具体规定。 8.3.2.设计和开发策划 8.3.2.1.根据公司确定的年度产品开发任务或者顾客要求等，由技术质保部 进行设计和开发的策划，设计和开发的策划需考虑以下内容： a)设计和开发活动的性质（如：全新产品设计、升级产品设计、客户订制产品 等）、持续时间和复杂程度； b)所需的过程阶段，包括适用的设计和开发评审； c)所需的设计和开发验证及确认活动； d)设计和开发过程涉及的职责和权限； e)产品和服务的设计和开发所需的内部和外部资源； f)设计和开发过程参与人员之间接口的控制需求； g)顾客和使用者参与设计和开发过程的需求； h)后续的产品和服务提供的要求； i)顾客和其他相关方期望的设计和开发过程得控制水平； j)证实已满足设计和开发要求所需的文件记录。 8.3.2.2.设计和开发的策划应形成《设计和开发计划书》。 8.3.3.设计和开发输入 8.3.3.1.设计和开发前，应针对具体类型的产品和服务确定设计和开发的基 本要求，形成设计和开发的输入，设计和开发的输入是设计和开发过程 的依据，设计和开发的输入应包括： a)产品和服务有关功能和性能要求。这类要求来自顾客或市场的需求期望（包 括顾客期望但没有表述出来的愿望或潜在的需求)及本公司确定的要求，一般包含在合同或研发项目建议书等技术文件中； b)适用的以前类似设计活动提供的信息； c)适用的法律法规要求、承诺执行的标准或行业规范，对国家强制性标准及规
门禁管理系统使用说明书
乌石化汽车定量装车系统 门禁管理系统使用说明书 河北珠峰仪器仪表设备有限公司 2013.08.03
目录 一、系统组成 (5) 二、道闸 (5) 1．主要特点 (5) 2. 设备组成 (6) 3. 基本工作原理 (7) 4. 设备使用说明 (7) 三、车辆检测器 (8) 1.车辆检测器的安装 8 2.主要技术参数 8 3.车辆检测器的接线图 8 4.车辆检测器灵敏度设置 9 四、门禁控制器 (9) 五、读卡器 (10) 六、车牌识别 (11) 七、摄像机 (12) 八、门禁控制管理软件 (13) 九、常见问题及解决方法 (14)
一、系统组成 门禁管理系统由行人出入口读卡器、行人大门电磁锁、车辆出入口道闸、摄像机、白光灯、车牌识别仪、控制主机、数据存储服务器等组成。 门禁控制系统组成 二、道闸 车辆出入口道闸采用深圳捷顺生成的JSDZ0203数字式道闸，该道闸采用先进的直流伺服技术和全电路无触点控制技术，使整机运行更加平稳、可靠。而且采用了数字化电路自学习检测功能，有效地杜绝砸车现象，使系统运行更安全可靠。并配备了标准的外接电气接口，可配置车辆检测器以及上位机，实现系统的自动控制。可广泛适用于道路管理、道路收费及停车场管理等系统中。1．主要特点 1)外形美观大方，结构轻巧；部件标准化，可方便更换；箱体铝合金制作，防 水防锈。 2)集光、电、机械控制于一体，操作灵活、方便，使用安全、可靠。
3)系统具有极限位置自锁功能或人为抬杆报警功能(可根据要求设定)。 4)采用先进的直流伺服控制技术，确保系统动作更加准确、平稳。 5)全电路无触点控制，确保系统运行更加安全、可靠。 6)采用PWM调速实现了无极变速，可根据现场需要在速度段内任意调整。 7)按钮滚动菜单设置方式，方便快捷设置闸机运行参数，可根据现场需要进行 设置。 8)采用数字化电路的自学习功能，采集闸杆运行数据并进行计算来判断闸杆是 否碰到障碍物，若检测碰到障碍物，闸杆则会立即自动升起。 9)强、弱电智能控制系统，除具有一般电气控制功能外，既可使用三联按钮、 遥控装置进行手动控制，也可通过车辆检测器进行自动控制，而且系统对外配置标准485电气接口，可通过电脑对其进行远程控制与管理。 10)手动开闸记忆功能：在系统自动运行中，非正常人为开闸数据将被系统自动 记录下来备查询，有效防止人为作弊。 11)开闸次数记忆功能：在系统自动运行中，道闸将会记忆上位机发出的开闸指 令次数，闸杆会保持开状态直到车辆检测器感应车次与开闸指令次数等同时才进行关闸动作。 12)手摇自动升杆功能：在意外断电情况下可用手摇摇柄轻轻摇动使关到位的闸 杆偏离水平方向约30度，闸杆则会自行升起。 13)温度控制功能：闸机可自动检测工作环境温度，并启动温控装置进行温度调 整，保证设备在高低温环境下正常工作。 14)各运动部件均已调整到最佳运动和平衡状态，故本机性能稳定，运行平稳， 噪声小，使用寿命长。 2. 设备组成 JSDZ0203道闸主要由主机、闸杆插头、闸杆等组成，而主机则由机箱、机芯和电控系统等组成 ,见下图。
版本号：B/0 页次：第1页共102页实施日期：2006.3.28 奇瑞汽车有限公司 新产品开发手册 编制/日期：过成军/2006.3.21 审核/日期：孙久红/2006.3.21 批准/日期：尹同耀/2006.3.28
修订页 编制/修订原因说明： 修订 原章节号现章节号修订内容说明备注编制/修订部门/人项目管理部/过成军 参加评审部门/人汽车工程研究院、规划设计院、采购公司、销售公司、国际公司、质量保证部、备件公司、物流公司、项目管理部、轿车公司、发动机公司、变速箱公司、信息技术部等 修订记录： 版本号提出部门/人修订人审核人批准人实施日期备注B/0 项目管理部/过成军过成军孙久红尹同耀2006.3.28
前言 本产品开发手册是在项目管理部、前企业管理部、汽车工程研究院、规划设计院、采购公司、销售公司、国际公司、质量保证部、备件公司等相关部门系统梳理新产品开发流程及其内部工作流程的基础上，共同研讨后完成的。 该手册告诉我们，产品“开发”不是产品研发部门一个部门的工作，而是所有与之相关的所有部门（包括外协单位）的共同工作。只是在不同的开发阶段，不同的部门参与的工作量不同。因此，一个新产品的开发，需要所有相关部门的共同参与，提前介入，才能保证信息的沟通，各环节连接顺畅。 而各部门的共同参与是建立在各部门分工明确的基础之上的。手册规定了每个部门在每个阶段应完成哪些工作；为启动某个阶段的工作，必须具备哪些前提条件；而完成这一阶段以后，应该完成哪些工作。即每个阶段均有明确的入口与出口，并由谁完成这些任务。 产品开发是一个“过程”。本手册阐述了以全新平台开发为模板的新产品开发过程。而车型开发和变型开发仅是该过程的简化，其内容可在具体的项目计划、项目定义与策划中进一步明确。产品开发的每个过程所需时间是客观存在的，如果违反这一规律要求，某些缺陷将会带给下一步工作引起返工；甚至影响市场信誉。 该手册的编制工作从2005年5月起至今，共10个月的时间。由于时间紧迫和对该手册的理解尚处于初始阶段，因此，我们肯请各相关部门能与我们共同探讨如何使该手册在我公司发挥更大的效益，缩短产品开发周期，规范产品开发行为，提高产品的竞争性，迎接市场的挑战。 在该手册编制过程中，我们得到了公司领导及相关部门的大力支持和帮助，在此，我们表示衷心的感谢。 项目管理部 2006年3月