Laboratoire de l’Informatique du Parallélisme
école Normale Supérieure de Lyon
UnitéMixte de Recherche CNRS-INRIA-ENS LYON-UCBL n o5668
A Monitoring and Visualization Tool and
Its Application for a Network Enabled
Server Platform
Rapha¨e l Bolze,
Eddy Caron,
Fr′e d′e ric
Desprez,
Georg Hoesch,
Cyril Pontvieux
April2006
Research Report N o2006-14
école Normale Supérieure de Lyon
46Allée d’Italie,69364Lyon Cedex
07,France
Téléphone:+33(0)4.72.72.80.37
Télécopieur:+33(0)4.72.72.80.80
Adresseélectronique:lip@ens-lyon.fr
A Monitoring and Visualization Tool and Its Application for a
Network Enabled Server Platform
Rapha¨e l Bolze,Eddy Caron,Fr′e d′e ric Desprez,Georg Hoesch,Cyril Pontvieux
April2006
Abstract
Monitoring grid platforms has recently gained a wide interest.This kind
of platform highly distributed across di?erent domains leads to several
design and implementation problems.We have designed a new mon-
itoring platform and visualization tool adapted for Network Enabled
Server systems.This environment,highly tunable for di?erent middle-
ware platforms has been successfully validated on the DIET platform.
In this paper,we present its architecture and main features as well as
details of the validation on the DIET environment and experimental
results on a large scale grid platform.
Keywords:Grid Computing,Monitoring,Visualization.
R′e sum′e
La surveillance des plates-formes de grilles a r′e cemment connu un in-
t′e r?e t important.Ce type de plate-forme distribu′e e entre des domaines
di?′e rents donne plusieurs probl`e mes de conception et d’impl′e mentation.
Nous avons con?c us une nouvelle plate-forme de surveillance et de vi-
sualisation adapt′e e`a des syst`e mes de type client/serveurs sur la grille.
Cet environment,largement adaptable pour d’autres infrastructures logi-
cielles a′e t′e valid′e avec succ`e s sur la plate-forme DIET.Dans ce rapport,
nous pr′e sentons son architecture et ses fonctionnalit′e s principales ainsi
que des d′e tails`a propos de sa validation sur la plate-forme DIET ainsi
que des r′e sultats exp′e rimentaux sur une plate-forme de grille`a grande
′e chelle.
Mots-cl′e s:Calcul sur Grille,surveillance,visualisation.
Monitoring and Visualization for DIET1 1Introduction
Understanding the behavior of distributed applications is indeed a di?cult task.Grid comput-ing adds another level of di?culty with heterogeneous sets of computers distributed over the network in di?erent administrative domains.However,grid computing middleware developers face this problem daily to optimize the performance of their applications.
We have designed a complete monitoring system based on an hierarchical object-oriented approach.This model and its implementation are generic and have been validated it on our DIET environment.The?rst target environment to be monitored belongs to the Network Enabled Servers[8]class.These environments like NetSolve[2],Ninf[9],or DIET[3]are built upon sets of servers that solve computational requests on behalf of clients.These clients?rst send their requests to a agent(meta-scheduler)that has to?nd a server using performance metrics.Agents can be distributed to improve the scalability of the system.This kind of highly distributed platform needs a scalable and e?cient monitoring software to understand its behavior.
A lot of work has been produced recently around grid platform monitoring[10]and a attempt of standardization has started within the Global Grid Forum.Most of the existing platform are highly tuned for speci?c grid environments.Around monitoring of Network Enabled Server systems,few work has been produced.The closest environment is visPerf[5] developed around NetSolve at the University of Tennessee.
In the rest of the paper,we?rst introduce the overall architecture and concepts around our tool(Section2).In the third section,we present an application to a Network Enabled Server system developed in our team called DIET(Section3).And?nally,before a conclusion and future work,we describe the cost model of our monitoring environment and some experimental results that show its small overhead.
2Visualization of a Distributed Platform:VizTool
In this section,we discuss the basic functionality of a monitoring system.We?rst de?ne the model provide for tools that needs to be monitored in distributed environments.Then we present the associate service that enable us to be aware of events that happened in a distributed environment.
2.1Simple Model for a Distributed Environment:vizTool Model
To be general and to provide for developer the freedom of de?ning his/her own platform, the basic properties and methods needed to monitor a distributed environment are de?ned. The main goal of a monitoring tool is to gather all events happened in this environment.An event is the?rst atomic object.It characterizes a simple message sent by a component to notify an action or a modi?cation.LogEvent is de?ned as this atomic event that happened in a distributed platform.This object has three main attributes:componentName gives the name of the component which is responsible of this event;time gives the time when this event happened,and message describes the event.
Then we de?ne an object which represents a concatenation of two linked events in the platform.In distributed environments,an event is often followed by another event which is the response.In Network Enabled Server(NES)environments,these two linked events are called a Request:one event informs of the start of an action,and another event informs of its
2R.Bolze,E.Caron,F.Desprez,G.Hoesch,C.Pontvieux end.To be able to know if these two events are linked,we need to identify them by an unique number called the request id.A Request has four main attributes:request id identi?es a request,beginTime,endTime,status gives the state of the Request.Four basic states have been de?ned:created no information of begin or end time are available;processing the request has been created and the begin time is known;done:begin and end time of the request are known;ambiguous:the request has been created and only the end time is known.As components are distributed,there are some cases where a request has?nished before being informed that it has began.
After modeling the activity of the platform,we need an object that manages all requests coming from di?erent components of the platform:ElementStats.ElementStats stores all done requests in a vector.This class provides two basic functions.The addRequest method stores a requests in the vector if request has done status else the request is stored in a bu?er.The findRequest method?nds a request with its request id.This ElementStats object is a member of a more general object called Element which models a component of the distributed environment.The Element object can have several properties,but we do not de?ne any other property to this object except his name.For example,an element can model a processor,but it can also model a server,or a cluster depends on the di?erent levels of abstraction.This approach gives the developer the opportunity to model and monitor with the granularity needed.Finally the vizTool model of the distributed environment is very simple and consists of four main classes(Fig.1):Element with two basic attributes:elStats and name.ElementStats models the activities of an element.It contains methods to obtain statistical information based on a requests object.Request object takes into account events that happened to the element,Requests objects are stored in elStats objects.LogEvent is the basic event in the distributed platform.It represents all atomic messages sent by all components and two linked LogEvent de?nes Request.
Figure1:Model of a monitoring tool.
Indeed this model is very general,and it needs to be tuned to the speci?c environment we want to monitor.However it gives a framework and a common base to monitor the distributed environment.We will discuss in next section how to re-use and adapt the vizTool model for one speci?c distributed environment.
2.2Event monitoring:LogService
An event monitoring system called LogService[6]has been designed.This monitoring service o?ers the capability to be aware of information that need to be gathered from a distributed
Monitoring and Visualization for DIET3 platform.The communication layer of LogService is based on Corba technology.LogCompo-nent attaches to a component and relays information and messages to logCentral.LogCentral collects messages received from LogComponents,then it stores or sends these messages to Log-Tools.LogTools connect themselves to logCentral and wait for messages.The main interest in LogService is that information are collected by a central point logCentral that receives lo-gEvents from LogComponents that are attached to the component that you want to monitor. The logCentral o?ers the possibility to re-send this information to several tools(LogTools) which are responsible for analyzing these messages and o?ering a comprehensive information to the user.
LogService de?nes and implements several functionalities.
Filtering mechanisms are used to reduce the number of messages sent.In order to decide which messages are required by a tool.The tools have to declare their?lter to the monitor(logCentral).
Event ordering is another important feature of a monitoring system.LogService handles this problem by the introduction of a global time line.When created,each message receives a time-stamp.The problem that can occur is that the system time can be di?erent on each host.LogService measures this di?erence internally and corrects the time-stamps of incoming messages accordingly.The time di?erence is corrected using the time stamp of the last ping that logCentral sent to LogComponent.However,incoming messages are still unsorted.Thus, the messages are bu?ered for a short period of time in order to deliver a sorted stream of messages to the tools.Messages that arrive out of order within this time are sorted in the bu?er and can be properly delivered.Although this induces a delivery-delay for messages, this mechanism guarantees the proper ordering of messages.As tools usually do not rely on true real-time delivery of messages this short delay is acceptable.
Dynamic system state:Components may connect and disconnect at runtime.A prob-lem that arises in distributed environments is the state of the application.This state may for example contain information on connected servers,their relationships,the active tasks,and many other pieces of information that depend on the application.The system state can be constructed from all events that occurred in the application.Some tools rely on this state to work properly.The problem appears if those speci?c tools do not receive all messages.This might occur as tools can connect to the monitor after the application has been started.In fact,this is quite probable as the lifetime of the distributed application can be much longer than the lifetime of a tool.As a consequence,the system state must be maintained and stored.In order to maintain a system state in a general way,LogService does not store the system state itself,but all messages which are required to construct it.These messages are identi?ed by their tag and stored in a special list.This list is forwarded to each tool con-nected.This process is transparent for the tool since it simply receives a number of messages that represent the state of the application.In order to further re?ne this concept,the list of important messages is also cleaned up by LogService.After a disconnection of a component the respective information is no longer relevant for the system state.Therefore,all messages sent by this component is removed from the list.
4R.Bolze,E.Caron,F.Desprez,G.Hoesch,C.Pontvieux
Figure2:DIET hierarchical organization.
3VizTool for DIET:vizDIET
3.1DIET Architecture
DIET(Distributed Interactive Engineering Toolbox)[4,3]is a set of hierarchical components to design Network Enabled Server systems over the grid.These systems are built upon servers managed through distributed scheduling agents.Clients ask these scheduling components to ?nd available servers(using some performance metrics and information about the location of data already on the network).The DIET architecture has been designed following a hierarchical approach.Thus it provides good scalability and can take into account physical network constraints.DIET is based on several components.First a Client is an application that uses DIET to solve problems in a RPC mode.The scheduler is scattered across a hierarchy of Agents.This hierarchy is made of one Master Agent(MA)and several Local Agents(LA).Fig.2shows a hierarchy built upon several DIET components.A Master Agent is the entry point of our environment and thus receives computation requests from clients attached to it.These requests refer to some DIET problems that can be solved by registered servers.A client can be connected to a MA by a speci?c name server or a web page which stores the various MA locations.The client asks the MA to?nd the most appropriate server to solve a speci?c request(?nd step).Then the MA collects computation abilities from the servers(by propagating the client request through its subtrees down to the servers) and chooses the best one according to some scheduling heuristics.A reference to the chosen server is sent back to the https://www.doczj.com/doc/6a6705224.html,putations(solve steps)are done by servers(both sequential and parallel)in front of which there are Server Daemons(SeD).For instance, a SeD can be located on the entry point of a parallel supercomputer.The information stored on a SeD is a list of data available on its server,the list of problems that can be solved on it, and all information concerning its load(memory and/or number of resources available,...).
3.2VizDIET model of DIET components and requests
DIET is a classic example of a distributed platform.There is a set of components which interact with each other.The goal for a monitoring tool for DIET is to know the state of the system,the activity of each component,and the status of user requests.We have integrated in all DIET components a LogComponent and they are able to relay information such as state
Monitoring and Visualization for DIET5 and activity by using the LogService mechanism.The model used for vizDIET is based on the basic model of vizTool,but vizDIET’s model has been specialized for DIET components.We consider each component of DIET(agents and server daemons)as an object which inherits from the element object.As there is a hierarchical architecture in DIET,the model will?t this property.Fig.3shows the simpli?ed UML schema of the model used to describe a DIET platform.
Figure3:DIET model of vizDIET
Figure4:vizDIET snapshot.
There are two main types of elements:ServerDaemons and Agents which inherit from Elements.Agents are then split into two classes:MasterAgents and LocalAgents which inherit from Agents.As described in the basic model each Element has a ElementStats object that stores and calculates information about the component that it monitors.MAs and LAs have nearly the same role in the DIET hierarchy,so their ElementStats share the same class: AgentStats which inherit for ElementStats.ServerDaemons’ElementStats is de?ned in its own speci?c object:ServerDaemonStats carries special methods and properties that di?er from MAs or LAs.
As described in Section3.1there are two main steps;one step to?nd and schedule a service,and one step to solve this service.Two main activities are represented by:schedule and compute information.When an agent takes a scheduling decision for a task,it is useful to know how the agent made its decision.This information is represented by the FindRequest
6R.Bolze,E.Caron,F.Desprez,G.Hoesch,C.Pontvieux object.When a SeD is computing a job we need to be aware of its state and to know when the computation begins and ends.This information is represented by SolveRequest object. FindRequest are attached to agents and SolveRequest are attached to SeDs but they both inherit from Request.The vizDIET model includes one more type of request:DIETRequest which is the aggregation of one FindRequest and one SolveRequest.DIETResquest object can be seen as a job execution in a DIET platform as seen by an end-user.This object carries one other information:latency which is the time between the end of a FindRequest and the start of a SolveRequest(see bottom right diagram in Fig.3).
Finally as proposed in the basic vizTool model,vizDIET uses a DIETLogEvent object inherited from LogEvent to de?ne and characterize an atomic Event/Log message in the DIET environment.In DIETLogEvent there are two more properties:logType and logCanal. these two properties are used to separate log messages and manage priority of log(see bottom left diagram in Fig.3).
DIETLogEvent messages can be separated in two di?erent types of messages:state and con?guration messages(in:a new element arrives in the platform,out:an element leaves the platform or fails,add service:SeD declare a new service into platform)and activity and informative messages(ask for sed:an agent looks for a SeD to execute a service, sed chosen:an agent has selected a list of SeD to execute a service,sed chosen:an agent has selected a list of SeD to execute a service,begin solve:a SeD begins computation for a service request,end solve:a SeD has?nished computation for a service request, data stored:a SeD has stored a dataset,data released:a SeD has deleted a dataset, data transfer begin:a SeD begins to send data to another SeD,data transfer end:a SeD ends data transfer).The?rst DIETLogEvent types de?ne a DIET platform and indicate its state.Activity and informative messages are atomic events which are used to de?ne objects such as FindRequest and SolveRequest.A pair of DIETlogEvents which are linked by the request id de?ne the corresponding type of request,for example one begin solve and one end solve DIETLogEvent from the same SeD and with the same request id de?ne a SolveRequest.
3.3Monitoring view of DIET with vizDIET
The?rst goal of vizDIET is to graphically represent the DIET hierarchy and to monitor its behavior.The vizDIET view is based on the basic view of VizTool,giving the possibility to show a lot of information extracted from event information received from logCentral(see Fig.4).
All objects and information de?ned in Section3.2about the DIET components are used to compute some properties of the system.
Average:represent the mean of elapsed time for each request.So by considering each request we can calculate the average time for one type of request(i.e.?ndTime,Solve-Time,and latency).
Max/min time:max/min time of all requests elapsed time.
Load:the number of requests computed at the same time.It is the number of requests that have a common intersection in the interval time represented by begin and end solve time.
Monitoring and Visualization for DIET7 Number of requests:this information is very useful.For example,one may be interested in the number of requests for a speci?c service on a speci?c SeD.
Latency:for each DIETRequest we can extract the latency between the end of a FindRequest and the beginning of a SolveRequest.This value represents the DIET’s latency that includes the time to transmit data from client to server,network latency,and any other time introduced by scheduling policy(ex:request queueing...).
Scheduling information:DIET’s agent return the sorted list of SeD that can compute the service asked by the client.This list is returned in sed chosen logEvent with all values that help agent to make his scheduling decision.
data information:with the aggregation of data information represented by logEvent such as data stored and data released,we are able to know the amount of data presents in DIET,but also the time needed to transfer data and historic of transfer for this data (data transfer begin,data transfer end).
Interaction with other systems:As LogService can relay whatever events,we can mon-itor the interactions of DIET components with JuxMem1[1]and know the amount of data read and write from JuxMem.
VizDIET can display a variety of information about the activity of a DIET platform. Fig.5show some example of vizDIET statistic output.In the Load graphic,the load of Element is calculated as the number of requests executed on the element at the same time. This information is represented in a graphic(left of Fig.5)that draws the load of a SeD or the load of DIET platform.With this graphic one knows immediately when requests are computed in parallel,and when there is overload or underload.In the Task?ow graphic, the?ow of requests is visualized.As requests are de?ned by a begin and end time,they can be represented in a task?ow chart to visualize scheduling information for each request.This view(middle of Fig.5)is very useful for observing the behavior of the scheduler and has been proven very useful for scheduler developers.Requests can be separated by using one color for requests executed on a SeD,or you can di?erentiate requests by using one color for each request involving a particular service.When requests are represented in a classic Gantt chart,the tasks repartition is known in the DIET platform,and also the number of tasks executed by a particular SeD.The Gantt chart(right of Fig.5only uses the information of the SolveRequest).
All of these methods can be applied to calculate values for one element such as a SeD,an Agent,or it can be applied to the entire DIET platform.It can also be applied to a speci?c set of requests restricted to one type of request.
4Platform Model and Experimental Results
According to the activity description given in Section3.1in DIET and vizDIET model,we can easily write a formula that gives the number of logEvents(and so the amount of data) that are generated by LogService in DIET.Let Nb log(req serv)be the number of logs for one request of service serv.Nb act is the number of logs corresponding to activity on platform. Nb desc is the number of logs to describe the DIET platform.Nb agent is the number of agents.
1JuxMem(Juxtaposed Memory)is a data sharing service for grid computing
8R.Bolze ,E.Caron ,F.Desprez ,G.Hoesch ,C.Pontvieux
Figure 5:Bar,task?ow,and Gantt graph in vizDIET stats.
Nb SeD is the number of SeDs.Nb SeD (serv )is the number of SeDs that can compute service serv ,Nb act (serv )is the number of activity logs for the service serv .Nb agent (serv )is the number of agents that have a SeD in their sub-tree that can compute service serv .req serv is the number of requests for service serv .
Nb log (req serv )=Nb desc +req serv .Nb act
Nb desc =Nb Agent +Nb SeD +
serv (Nb SeD (serv ))Nb act =
serv (Nb act (serv ))
Nb act (serv )=2.(Nb agent (serv )+1)
This formula can be simpli?ed if we considerate a platform with only one service per SeD:
Nb log (req )=Nb desc +req.Nb act
Nb desc =Nb Agent +2.Nb SeD
Nb act =2.(Nb Agent +1)
Now let’s take care of the size of messages sent to logCentral in the case of one service per SeD.Let S log (req )be the size of logs depending of the number of requests.S desc is the size
of the message sent to logCentral to describe the platform (S node desc is the size of a message to describe one node).The message is the same for an agent,a SeD,and a service.S act is the
size of message that notify activity in the DIET platform:S ask is the size of the message that noti?es the event ask for sed .S f is a ?xed size for the message sed chosen .S si is the size of message containing schedule information of SeD.It is multiplied by agent (Nb SeD (agent ))which represents the sum of SeDs that are under the sub-trees for each agent.And ?nally,S solve is the size of message which noti?es the SeD solves service.
S log (req )=S desc +req.S act
S desc =S node desc .(Nb Agent +2.Nb SeD )
S act =Nb agent .S ask +Nb agent .S f + agent
(Nb SeD (agent ).S si )+S solve
We made some experiments to evaluate the scalability of logCentral to manage a DIET platform.These experiments are made with the worst DIET platform topology (i.e.:that
Monitoring and Visualization for DIET9 Nb of nodes Nb act Min time/log Mean time/log Max time/log Standard deviation 1618003e-06s 5.33e-06s 1.8e-05s 1.29e-06s
3234003e-06s 6.60e-06s 3.1e-05s 2.30e-06s
6466003e-06s8.81e-06s 1.94e-04s 4.75e-06s
128130004e-06s 1.53e-05s 5.33e-04s 1.42e-05s Table1:LogCentral behavior:100client requests with di?erent numbers of DIET nodes.
maximize the number and the size of messages that are sent to the logCentral).This topology is a rake tree2where there are the same number of SeDs and Agents3.There are10LogTools connected to the logCentral to received messages,and for each experiment,there are100 client’s requests on the DIET platform.The results of experiments are presented in Table1. These experiments show that logCentral is scalable.Even for a large platform,the maximum time to forward one log to10LogTools is about0.5ms.
VizDIET and LogService are optional services that can be used with DIET.But as with any other monitoring and information service for distributed systems as[7],LogService introduces overheads with the transfer of data and information production.In this part we evaluate and quantify these overheads with a case study.
We choose a DIET hierarchy with1MA and10SeDs.Each SeD executes a DGEMM service.We study the performance of the DIET hierarchy in terms of number of requests per second the platform can compute.Each20s there are two more clients that ask for the DGEMM service.All clients call DGEMM service on two small matrices(10x10),wait for the result,and then call the service again until the end of the experiment.Fig.6shows the average on4experiments for the DIET platform with and without LogService.
The goal of the case study is not to know the DIET performance limits,but to compare the performance of DIET when LogService is turned on or o?and also the behavior near the performance limits of the DIET platform.Fig.6shows that the LogService does not signi?cantly a?ect the overall performance of the platform,and the behavior of the platform is the same with or without LogService.The number of requests that was performed during the entire experiment is256838(mean on the4experiments).
Now thanks to formulae given in Section4.There were21informative logEvents and 1030804activity logEvents.In total,the experience described above has generated1030825 logEvents.
5Conclusion and Future Work
VizTool is a basic framework that allows the speci?cation of di?erent models on distributed platforms.The VizTool model is very simple and generic to be used for various types of distributed environments.This model has been tested and validated in VizDIET for the monitoring of the DIET platform.
There are many others possibilities of improvement of VizDIET.More information can be added on the scheduling side(statistics,other measures like throughput,fairness,slowdown, 2A rake tree is a chain where all leaves are attached on the last node.
3This result has been proven,but this demonstration is not present in this paper.
10
R.Bolze ,E.Caron ,F.Desprez ,G.Hoesch ,C.Pontvieux 0 50
100
150
200 250
300
350
0 20 40 60 80 100 120 140 160 180 200
R e q u e s t s /s Time
average?log average?nolog 0 200
400
600
800 1000 1200
1400
1600
0 20 40 60 80 100 120 140 160 180 200
R e q u e s t s /s Time
average?log average?nolog Figure 6:Comparison of request processing rate with and without LogService.
...).The main improvement that remains to be done concerns the scalability of the visual-ization (which is a common issue for every large scale monitoring framework).Features like zooming on the architecture or more speci?cally for the DIET platform expand/un-expand a branch of the hierarchy will be developed.
Acknowledgements
This work was supported in part by the ACI GRID,the RNTL,and the GRID5000projects of the french department of research.
References
[1]G.Antoniu,L.Boug′e ,and M.Jan.Juxmem:An adaptive supportive platform for data
sharing on the grid.Scalable Computing:Practice and Experience ,6(3):45–55,November 2005.
[2]D.Arnold,S.Agrawal,S.Blackford,J.Dongarra,https://www.doczj.com/doc/6a6705224.html,ler,K.Sagi,Z.Shi,and S.Vad-
https://www.doczj.com/doc/6a6705224.html,ers’Guide to NetSolve https://www.doczj.com/doc/6a6705224.html,puter Science Dept.Technical Report CS-01-467,University of Tennessee,Knoxville,TN,July 2001.https://www.doczj.com/doc/6a6705224.html,/netsolve/.
Monitoring and Visualization for DIET11
[3]E.Caron and F.Desprez.DIET:A Scalable Toolbox to Build Network Enabled Servers
on the Grid.International Journal of High Performance Computing Applications,2006.
To appear.
[4]DIET.http://www.graal.ens-lyon.fr/DIET.
[5]D.W.Lee,J.Dongarra,and R.S.Ramakrishna.visPerf:Monitoring Tool for Grid
Computing.In P.M.A Sloot et al.,editor,ICCS’03,volume2659of Lecture Notes in
Computer Science,pages233–243,2003.
[6]LogService.http://graal.ens-lyon.fr/DIET/logservice.html.
[7]M.L.Massie,B.N.Chun,and D.E.Culler.The Ganglia Distributed Monitoring System:
Design,Implementation,and Experience.Parallel Computing,2003.(submitted).
[8]S.Matsuoka and https://www.doczj.com/doc/6a6705224.html,work-Enabled Server Systems and the Computational
Grid.https://www.doczj.com/doc/6a6705224.html,/～dbader/grid/WhitePapers/GF4-WG3-NES-whitepaper-draft-000705.pdf, July2000.Grid Forum,Advanced Programming Models Working Group whitepaper
(draft).
[9]H.Nakada,M.Sato,and S.Sekiguchi.Design and Implementations of Ninf:towards a
Global Computing Infrastructure.Future Generation Computing Systems,Metacomput-
ing Issue,15(5-6):649–658,1999.https://www.doczj.com/doc/6a6705224.html,/papers/papers.shtml.
[10]S.Zanikolas and R.Sakellariou.A Taxonomy of Grid Monitoring Systems.Future
Generation Computer Systems,21:163–188,2005.
机械加工中的刀具管理系统 随着加工系统的高速化、无人化及智能化发展，为了提高加工产品的品质，刀具管理的必要性尤为重要。因此，各企业为了提高生产效率，减少成本，都竞相引入刀具管理系统或建立刀具数据库。 1 刀具管理系统 机械加工中刀具管理系统是对N C 设备所需的刀具(铣刀和板料等1的基本信息、在库及购买的管理。 其主要职能有：1 ) 刀具管理：一般N C 用刀具的入库、检收、补充及报废管理; 2 ) S ( 自动化)刀具管理：对FM s 设备所需的刀柄和主轴管理； 3 ) 库房／购买管理：刀具的异体、预算、购买、订货及来历等的管理。 2 刀具室 刀具室的建立，不单单是作为一个库房来存在，它要完成的任务在制作过程中应该起到很大的作用，工作做的如何直接影响到产品质量，生产周期以及加工成本。 刀具室要记录各个设备的月消耗，通过对比分析来确定刀具使用情况，以便于更好的做出成本分析。 刀具室除了基础的刀具配送外，还应承担其他的任务。 1 ) 一般信息——刀具编号、材质、规格、刀具长度、直径及形状等。刀具室应该对刀具进行统一编号，以便于日后管理，并将刀具相关信息录入电脑记录，例如：F 1 2 —1 ( 编号为“l ”的直径中1 2 m l T l 平刀) ；B 1 0 —2 ( 编号为“2 ”的直径①1 0 m m球刀) 。当然可根据适合自己习惯的方法进行编号，录入刀具的一些基本参数， 以方便库管员根据加工程序单所示的的参数找到相应的刀具。 2 ) 加工信息——刀具寿命、刀具磨损量及切削条件。库管员根据现场反馈情况和日常统计明确刀具的使用寿命，以此来确定刀具的更换周期，及时地更新刀具磨损量，根据实际加工情况合理的配备合适的刀具，切勿大材小用。 3 ) 库房分析——刀具选取、品质水准、刀具修理及研磨、特殊刀具制作、供应商考核、 月消耗及设备考核。刀具管理可以说是～个很复杂的工作，不单单是把刀具送到现场，进行账目统计，以及刀具维修这么简单。在此过程中还要根据本部门所处的水准和加工类型来合理选用刀具。例如：对于大型汽车覆盖件，在做精加工时要使用品质有保证的机床 和刀具。我们公司是采用日本东芝高速龙门铣配黛杰高精度球刀来完成作业，若是做E 类 件就不必使用这类设备和刀具，国产刀具完全能够满足精度和面品需要。 选用刀具的时候，是用价高的还是价低的，要考虑刀具的性价比，例如，在建厂初期，
软件项目管理习题 第一章绪论 1.列举你在执行IT相关任务时曾碰到的问题。试把这些问题按频率和影响大小分别排序。对每一个问题，考虑是否可以通过某种方法降低发生的可能性。 2.软件工程的三个冃标是什么，以什么衡量是否达到冃标？ 3.软件工程活动包括哪些？那些活动需要有最终用户的参与？每个过程需要有怎样的文档产出？ 4.设计包括哪两个阶段，具体任务，干系人有什么区别？ 5.软件工程的原则有哪些？ 6.你能说出哪些软件工程模型，他们各自有什么有缺点,适用于怎样的系统？ 7.有人说“线性模型已经过时了，有着诸多缺点，不需要再了解它。”你怎么看待这种说法？线性模型和其他模型的关系是怎样的？ 8.在下列哪一个阶段项日发起人对项目的范围、质量、时间和成本有最大的影响力，为什么？ 9.项1=1的定义是什么，有什么特点，请给出三个是项日的例子，并给出三个不是项日的例子。 10.软件项目与一般的项目的区別在什么地方 11.判断以下活动中哪些是项目，哪些不是项目，并请说明理由。（1）升级某政府部门的办公自动化系统（2）打字员打印文件（3）报考软件学院软件工程硕士研究生（4）购买家用轿车（5）每天骑千上班 12.项忖生命周期包括哪些阶段？哪个阶段具冇最大的不确定性？各个阶段的活动主要冇哪 些？ 13.项目管理的六要素有哪些？相互之间是什么关系。TQC又指什么？ 14.怎样衡量项目是否成功？ 15.项目管理分哪几大知识体系，它们Z间什么关系？ 16.在选择职员时，应该考虑哪些因索？ 17.管理者是否应该和小组中更多的普通员T交朋友，并和他们打成一片？ 18.如果项1=1快结束时，忽然有一个很重要的，但非常耗时的变更，你作为项目经历应该怎么做 19.为什么说时间和人员不能交换？试说明其原因。 20.你能列出那些人际关系的矛盾？试阐述可能的解决方法。 第二章需求管理 1.软件需求的定义是什么，分别从用户角度，开发者角度，相关文档角度给以阐述 2.描述软件需求要做的五项主要事悄指什么。 3.软件需求过程与那些过程相关，是怎样的关系？
对于一个项目的评估、分析，需要参考很多要素，从资本投入方面来讲，可以用六个要素来衡量。对于投资者来说，在投资前都应该搞清楚这六个要素在投资中的作用，否者最好不要去投入。 一般来说，在投资前，投资者在资本投入方面，可以通过以下六个要素来衡量。 1、项目初期成本 在项目正式运作之前，需要投入多少钱，这个钱可能成为将来正式运作之后很大的包袱。一些企业由于建厂期间走的弯路太多，建起一个远远超出预算的厂，会推迟项目评估时预计的盈亏平衡时间。 2、每一阶段发生的费用 一般按年算，第一年要花多少，第二年要花多少………当然，最好是清楚每个月的大致情况。而且最好能分出哪些是固定不变的，比如房租;哪些是随着其他因素，比如产量的变化而变化;还有哪些是自己能控制的，比如自己的工资可以少拿一些;哪些是无法控制的，比如国家规定的税费。 3、投资的生命期 多少年之后，这个项目就差不多等于玩完了，再运作下去也不会有赚钱的可能。这也可以结合产品的生命周期，但不少项目不到产品的生命周期结束就结束了。 4、现金产生的时间和数量 什么时候开始能有白花花的银子流进来，也就是要预计什么时候开始有销售了，或者有广告收入，或者有人给顾问费了。 5、对原企业的影响 这个项目有没有可能为其他项目增加利润，比如购入其他项目的产品做原料，或者制造麻烦，比如自己跟自己竞争。 6、需要的营运资金
1、项目实施范围 客户买了哪些模块，实施这些模块将给客户带来什么价值，这是项目的点睛之处。 我常跟客户说ERP是一套管理工具，是一个数据统计和分析的工具。通过它给企业带来价值的创新，而这些价值体现在职能分工、还是业务流程、我们一定要界定清楚。只有界定了、清楚了我们的实施目标，才能为后续项目顺利验收作好铺垫。 所以项目的实施范围条款，在我们的《实施工作任务书》上，一定要做的非常细致，而且一定要项目对方负责人签字确认。 2、项目计划管理 项目计划管理，是保障项目按质按量交付的一个过程，这是项目成功的核心关键。 确定项目范围之后，接下来就是计划管理；想必是顾问的都知道，对于企业而言，时间上的配合实在是不敢恭维。不管是项目到后来是好是坏，甚至有些企业从项目一开始就有并不打算真正把它做好的念头。但不管怎样，对于顾问而言，项目或许没做好，客户也闭着眼睛签字验收了，但凭心而论，就是过不了心里不痛快那道坑。所以，在这种意识里，我们在项目过程中，除了是保障项目的责任不让我们去承担，更重要的是通过有效的计划管理，带动和促进客户的工作积极性。 作为顾问，我们如果没有计划，就没有压力和工作轻重区分；虽然计划跟不上变化，但计划一定要强化执行，尤其是对于我们顾问方，一定要坚持与客户方确认，并每周将《项目周报告及计划》通报相关领导！ 3、项目沟通问题 项目沟通问题，不是跟客户关系做得好不好，而是项目过程有没有做好文档控制的问题。 沟通问题或许是困扰每个顾问的难点，尤其是与对方高层的沟通。在这里，我只想说一句，所有项目相关的事宜均需以书面表达，关键文档还是要作现场确认，切勿以为你跟对方关系不错，就可以不把它当一回事；当项目真正出问题了，那个时候你跟对方的关系是极其脆弱的！ 所以我的观点是：作为顾问，日常《实施日志》的繁琐确认，总比撕开脆弱的关系要强千倍万倍。 4、流程重组意志 ERP项目管理，换句话其实是流程重组过程的管理，该坚持的还是要坚持！
基于数据库的刀具管理系统的设计与实现 来源:数控机床网作者:数控车床栏目:行业动态 本文通过需求分析、数据库设计和实现，提出了快速刀具查询和数据库管理系统，从而使刀具适应了数控机床高速、高效和自动化程 度高的特点，提高了刀具利用率以及数控加工的灵活性与效率，最终降低了新产品的开发成本，缩短了试制周期。 一、前言 随着人们对机械加工精度、效率以及特殊工件加工要求的提高，数控车间和加工中心已广泛应用于现代化大中型企业。在加工中心中 ，刀具管理是一项重要任务，它不仅为智能制造技术系统和PDM/ERP系统提供有效的技术支持，而且可为制造业进行网络化的虚拟制 造技术研究与开发奠定技术基础，是关系到加工产品的技术先进性、质量可靠性、供货周期、制造成本的关键环节。 作为加工中心工作中不可缺少的步骤，如何有效地组织刀具是影响加工中心乃至柔性制造系统效率的一个重要因素，现有的问题主要 是以下几个方面：如何组织刀具使刀具的存取更方便；如何调度刀具使刀具交换次数最少；如何选配刀具使刀具准备时间最短、利用 率最高。总之，研究刀具资源的管理就是用最小的刀具资源来达到生产要求，尽可能减少对刀具资源的占有。 经过大量调研和分析，该系统以VC++为开发工具，以Microsoft SQL Server 2000为后台数据库建立。 二、数据库设计 车间刀具的数据库管理系统，必须能满足不同用户的需要和要求，这里只详细说明设计过程中的概念结构设计和安全性设计。 1．概念结构设计 该数据库是一套高端数控程序管理系统，可以对程序的编辑者、刀具清单进行管理，还可以对数控程序的各种信息，如程序号、图号 、零件号、机床、用户信息等进行管理，下面是创建与数据库相关部分的实体关系图（ERD），如图1所示。 图1 DNC数据库总体E-R图 2．安全性设计 用户只能用账号登陆到应用软件，通过应用软件访问数据库，而没有其他途径操作数据库。对用户账号的密码进行加密处理，确保在 任何地方都不会出现密码的明文。除非是数据库管理员才能看到，因为他拥有应用软件的所有权限。 确定每个角色对数据库表的操作权限，在应用时再为用户分配角色。角色的权限如表1所示。 表1 角色权限表 三、后台数据库的实现 以VC++开发工具，运用VC++的数据库接口技术、Microsoft SQL Server2000为后台数据库进行dncdb数据库的设计，其具体设计过 程包括建立数据库、建立表、建立关系、实现数据完整性等几个步骤，下面分别介绍。 1．建立数据库
1、项目是一个组织为实现自己既定的目标，在一定的时间、人员和资源约束条件下，所开 展的一种具有一定独特性的一次性工作。目的性独特性一次性制约性其他特性 2、项目生命期阶段的划分：启动阶段，计划阶段，执行阶段：实施和控制阶段，收尾阶段 3、项目中的重大事件，通常是指一个主要可交付成果的完成。它是项目进程中的一些重要 标记，是在规划阶段应该重点考虑的关键点。里程碑既不占用时间也不消耗资源。项目干系人:也可称为利益关系人，或利益相关者，是指积极参与项目、其利益受到该项目影响的个人或组织。 4、理解项目管理的含义、特征、基本要素及工作过程 （1）对象：项目管理的对象是项目，一般企业管理的对象是作业； （2）目标：项目管理的目标是确保项目能够成功。企业管理的目标是使每个作业都能高效率地展开，以求企业达到一定的经济效益； （3）内容：项目管理的内容包括项目的范围管理、项目的组织管理、项目的质量管理、项目的费用管理和项目的时间管理等内容，而且每一项管理都含有风险。一般企业管理其内容也许更丰富，涉及面更广，但它的风险性相对比较小； (4）过程：项目管理非常强调其过程性。一般企业管理强调的是创造一个稳定的环境，使各项作业能以最高的效率进行，侧重于作业点的效率 （5）责任：项目管理强调对整个项目负责，一般企业管理中强调分工，强调各部门按作业规范做好自己的本职工作，所以责任在其规定的作业范围内 （6）手段：项目管理中所能采取的手段，一般不同于普通的企业管理方法。 六要素：质量、进度、成本、范围、组织和客户满意度 5、各种项目组织结构的优缺点（特点）职能型组织机构具有明确的等级划分，每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合。职能组织的行为机制偏重行政命令，容易产生官僚主义行为，不易发挥人的主观能动性，难以对其环境问题作出及时的反应。项目型组织结构的特点：优点：注重客户，目标明确，便于统一指挥。有利于项目控制。有利于全面型人才的成长。缺点：机构重复及资源闲置，成本较高。项目间缺乏知识信息交流，不利于企业专业技术水平的提高。不稳定性。矩阵优点：有利于资源共享。成员无后顾之忧。注重客户。缺点：责任不明确。双层汇报关系，需要平衡权利。多个项目资源难以平衡 6、了解项目生命期阶段与项目管理过程的关系：项目生命期一般包括四个阶段没有重复，是一次性结束的，是从项目的实现过程的角度考虑的。项目管理的五个过程（启动、计划、执行、控制、收尾）并不是独立的一次性过程，它贯穿于项目生命期的每一个阶段。 7、认识项目管理知识体系PMBOK：项目整体管理（PIM）项目范围管理（PSM）项目人力资源管理（ PHRM ）项目进度管理（PTM ）项目成本管理（PCM ）项目质量管理（ PQM ）项目采购管理（ PPM ）项目沟通与冲突管理（ PCM ）项目风险管理（ PRM ） 1、项目整合管理，是应用系统论思想、理念和技术方法保证项目的进度、费用、资源、质量等要素之间相互协调所需要的过程；项目成组管理：主要是管理具有相似性质的项目，把这些项目放在一起，形成一个项目组，进行统一管理，以产生规模效益，提高项目管理效率。项目在工作方法、所需人员等方面具有相似性，注重提高项目的效率。项目组合管理：则是从企业整体利益出发，动态地选择不具类似性质的项目，对企业所拥有的或可以获得的生产要素和资源进行选择、匹配、优化组合，从而有效地、优化地分配企业资源，分散企业风险，以达到企业效益最大化，提高企业核心竞争能力的目的。 3、项目组合与企业战略之间的关系：首先要保证所组合的项目有利于实现企业经营战略 其次在项目组合中合理分配资源可以使企业的一些战略目标的组合价值最大化。 项目组合可以培养和提升企业的核心竞争力，应用组织学习手段，将不同项目的技术知识整合起来，形成关键知识或产生新的知识，可以培养、拓展和强化企业的核心竞争力。 4、了解三种项目管理的成熟度模型CMM ，OPM3， K-PMMM 1、项目基准计划：项目的基准计划（baseline）是项目在最初启动时订出的计划，也即初始拟定的计划。项目基线：项目基线是特指项目的规范、应用标准、进度指标、成本指标，以及人员和其他资源使用指标等。 2、项目计划的分类？按照项目计划制定的过程划分：概念性计划（确定项目的战略导向和重点）详细计划（确定详细的工作分解图）滚动计划（在已有计划基础上制定的计划） 3、项目计划的编制程序（1）定义项目的交付物（2）确定任务，进行工作分解（3）建立逻辑关系图（4）为任务分配时间（5）确定责任部门和人的可支配时间（6）为任务分配资源（7）确定支持性任务（8）计划汇总审批与下达
摘 要 我国的刀具管理技术与世界发达国家相比，发展还较为滞后。在制造业进入 信息化、智能化的今天，用计算机技术实现工艺问题中的刀具选用，和在CIMS 中实现刀具的自动调配、修整、报废、订购和技术统计等问题，已经成为企业降 低使用刀具成本，提高生产效率的重要途径。为了适应新的市场环境，企业必须 使生产柔性化以快速响应市场。而刀具在整个生产过程中占有相当重要的地位， 因此提高刀具利用率，对刀具进行有效地管理就变得十分重要。刀具管理系统是 先进制造技术领域的重要研究课题， 对于全面增强企业应变能力和市场竞争力有 着十分重要的意义。 本文探讨了刀具管理系统的主要技术，主要有：（1）对刀具的编码系统进行 了分析，并结合企业的状况，设计了数控车间的刀具编码（2）建立了添加、删 除和统计刀具信息的模型。（3）使用 SQL Server 2008 作为物理数据库建立了数 据之间的联系。 该系统具有较强的实用性， 为企业提高生产率， 促进企业各部门的信息共享， 提供了有效的工具。 关键词：刀具管理系统；SQL Server；数据库
Abstract China tool management technology compared with developed countries,is lagging behind. Tool used in the process issues with computer technology, manufacturing information, intelligence, and in CIMS tool automatically deploy, trim, scrap, ordering and technical statistics, has become the enterprises to reduce the use of tool costs,and it is an important way to improve production efficiency. In order to adapt to the new market environment, companies must make the production flexibility to respond quickly to market. Tool occupies a very important position in the entire production process, thereby increasing the utilization of the tool, the tool to effectively manage becomes very important. The tool management system is an important research topic in the field of advanced manufacturing technology, comprehensively enhance the resilience and competitiveness in the market has a very important significance. This paper discusses the tool management system technologies,mainly in the following: (1) analysis of the coding system of the tool,combined with the state of the business, the design of the NC workshop tool coding (2) established a model to add, delete, and statistical tool information. (3) using SQL Server 2008 as a physical database to establish a link between the data. The system has a strong practical and provides an effective tool for enterprises to improve productivity to promote various departments of the enterprise information sharing. Key words:Tool management system? SQL Server；data base
感受现代科技 【学习目标】 1、知识：感受现代科技给人类生活带来的新变化，认识科技与生活，科技发展与社会发展的关系，懂得“科学技术是第一生产力”的道理。 2、能力与情感：感悟现代科技的神奇与力量，理解科技是社会发展的强大推力，激发学生 对科技重要性的认识，增强学生对科学的兴趣，培养学生热爱科学的精神。 3、过程与方法：依据教学内容和学生的认识规律设置了“课前预习”、“课堂助学”、“课堂巩固”、“课后拓学”、“教学反思”五个模块的教学整合，运用多媒体等教学手段，采用自主体验、 探究活动、案例情境等方法来完成教学目标。 【学习重点、难点】 领略现代科技的神奇与力量，理解“科技是第一生产力”。 【学习过程】 一、预习初探： （一）快快行动，书外的知识真有趣： 1、生活体验：观察生活，请你说说我们身边有哪些科技产品？例举实例说说这些科技产品给我们的生活带来哪些新变化？ 2、想象天地：展现你的想象天份，想象你准备发明一样科技产品，使你的未来生活更美好。 3、图片收集：上网收集有关科技产品的图片，准备创办科技小展览，领略现代科技的神 奇与力量。 （二）阅读课本，书本的知识真寻味： 4、我们现在的生活与科技________________。丰足的衣食，舒适的住行，千百年来一直是人类_________________。 5、科学技术是________________的强大推力，是________生产力。______________已成为当代经济发展的火车头。 6、________________是人类文明的标志。科学技术的进步为人类创造了巨大的 ______________和_________________。
软件项目管理习题 第一章绪论（13题） ★2．软件工程的三个目标是什么，以什么衡量是否达到目标？ 可用性；正确性；经济性。以用户需求及项目计划来衡量是否达到目标 ★3．软件工程活动包括哪些？那些活动需要有最终用户的参与？每个过程需要有怎样的文档产出？ 问题定义：关于问题性质、工程目标和规模的书面报告； 可行性研究：可行性分析报告； 需求分析：需求分析说明书； 设计：概要设计说明书，详细设计说明书 实现：无 确认：测试计划，测试报告 支持：操作手册，用户手册。 其中需要有最终用户参与的有：问题定义，可行性研究，需求分析，确认，支持。 ★5．软件工程的原则有哪些？ （1）选取适宜的开发模型。（2）采用合适的设计方法。（3）提供高质量的工程支持。（4）重视开发过程的管理。 ★6．你能说出哪些软件工程模型，他们各自有什么有缺点,适用于怎样的系统？ 一、瀑布模型：（1）实际的项目很少按照该模型给出的顺序进行；（2）用户常常难以清楚地给出所有需求，而线性顺序模型却要求如此；（3）用户必须要有耐心；（4）开发者常常被不必要地耽搁；（5）项目相关人员之间的敌对关系。适用于开发团队熟悉的系统。二、原型化模型：（1）原型作为“第一个系统”，是我们应该抛弃的；（2）趋于用户的压力，用户会要求将原型改成最终的工作产品；（3）趋于开发进度压力及设计结构的压力，无法更改应用模块。适用于：用户定义了软件的一组一般性目标，但不能标识出详细的输入、处理及输出需求以及开发者不能确定有效的算法或技术适应性的系统。 快速应用(RAD) 过程模型: 1、只能用于信息系统。 2、对于较大的项目需要足够的人力资源去建造足够的R AD组。 3、开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。 4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造R AD所需要的构件就会有问题。 5、技术风险很高的情况下不适合这种模型。 螺旋模型: 、需要相当的风险分析评估的专门技术，且成功依赖于这种技术。 2、很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。 3、这种模型相对比较新，应用不广泛，其功效需要进一步的验证。 优点： 1、对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。 增量过程模型：缺点：
Smart Crib 刀具管理系统 系统概述 Smart Crib 是北京兰光创新科技有限公司集国外先进的刀具管理理念与国内用户的具体需要相结合而研制开发的刀具管理平台。Smart Crib 刀具管理系统具有完善的数据库管理功能，能够非常灵活、高效地对不同生产厂家、不同类型的刀具进行多库房管理，规范的出入库操作，智能的组合刀具拆装，丰富的库存统计等各种强大的功能，Smart Crib 刀具管理系统完全可以满足各类机械企业对刀具管理的各种需求。 Smart Crib 采用目前最前沿的B/S 架构，充分利用Internet 技术，实现网络内刀具信息共享，网络内任意一台计算机无需任何配置均可通过浏览器登录系统，并获得自己需要的刀具信息。人性化的设计理念、友好的人机对话界面及强大的管理功能，Smart Crib 刀具管理系统可以让您轻松获得刀具的最优资源配置，有效地降低生产中的刀具成本，并在最短时间内完成刀具准备，明显地提高机床的利用率。 主要模块 ?系统管理（用户管理，运行日志，数据远程备份，系统初始化，车间维护，系统维护）； ?标准数据维护（参考数据定义，刀具定义，组装刀具定义，刀具包定义）； ?刀柄管理（刀柄新购、出入库、报损管理、多功能查询）； ?附件管理（附件新购、出入库、报损管理、多功能查询）； ?组合刀具管理（组合刀具组装、借出、改装、拆卸、多功能查询）； ?贵重刀具管理（贵重刀具新购、出入库、打磨维修、报损、维修入库，刀具寿命管理）； ?量具管理（量具新购、出入库、校测、报损管理、多功能查询）； ?夹具管理（新购/新做、出入库、报损管理、多功能查询）； ?非标刀具设计（非标刀具的设计、审批、及出入库、报损管理、多功能查询）； ?库房预警、自动订货功能； ?报表管理（附件类报表模块、刀柄类报表模块、贵重刀具类报表）； ?友情连接；
PMP认证的六大成功要素 来源：PMU项目管理者联盟作者：吴溪 据统计，在世界范围内，参加PMP认证考试并且成功通过PMP认证考试的人与日俱增。尤其是200 5年底，因为正值改版，很多人希望搭上PMBOK2000的最后一班车，因此参加PMP认证考试的人数就更多了。 借此机会，分享一下我个人在考PMP认证考试过程中的一点经验。本文将逐步引述我个人总结的成功通过PMP认证考试的七大成功要素。 具备充分项目管理基本理论知识和实践经验是通过PMP认证考试的第一大因素。 我个人虽然此前没有受过专业系统性的项目管理培训，特别是针对PMBOK的系统性培训。但是此前因为一直在IT行业从事过程改进工作，因此在项目管理理论知识以及实践方面还是有一些了解。在学习过程中，绝大部分内容都是老朋友；另外一些是似曾相识或者点头之交。很少有从没听过的，例如折旧法之类，但是这部分内容被用来当考点的机率低之再低，已然快要低到尘埃，但是还没有开出花来，因此，基本上可以忽略不计。 基础知识和实践经验本身是非常重要的基础，另一方面，可以培养我们的思维方式，便于我们在遇到项目管理相关的新的知识点的时候，能更快地理解并应用。 三次学习循环是成功通过PMP认证考试的第二大成功因素。 三次学习循环是指看书－做考题－总结经验并写小结－再看书－再做曾经做错的考题－再看小结－考试前再看小结。 通过这个过程可以帮我们在准备考试期间不断积累知识和对PMBOK要点的理解。如果对PMBOK的要点有了解，模考的时候，你会发现每做一道题，你都能知道这道题究竟是要考什么。达到这个效果，肯定能通过PMP认证考试。 我个人比较懒散。因此非常崇尚考试。一旦做错了，这种结局会触发我去思考我为什么错了，要怎样才能不犯错。因此在准备考试过程中，我的主要精力是做考试题。基本上每章做了40道考题。一旦我做错考题，我会将思考后得出的结论写在考题的旁边。然后我会再回去看书，仔细阅读相关的要点。 下一次我在做另一个章节的考题之前，我会再做一遍上一次做错的考题，顺便温习一下我的思考小结。据说有人研究过，一般重复三次，这东西就是你的了。而最利于人记忆的组合是三。因此在模考前的两个晚上，我重看我做错的题和思考小结。看完后觉得思路很清晰，对PMBOK也很明白，信心大增。 正确阅读PMBOK是成功通过PMP认证考试的第三大因素 PMP考试的主题基本上来自于PMBOK。少部分来自于其知识体系拓展，而且这部分考题在200道考题中的比例相对较小。
高效的刀具管理软件解决方案ToolExpert 现代的制造车间以数控机床为主，配置各种CAD/CAM、PDM和ERP系统，由于各系统之间相互独立，导致数据无法交换，形成信息孤岛，数据需要重复输入现象严重，信息沟通多通过纸质文件进行，效率低下，而且制造文件的版本控制难以实现。据统计，制造车间NC机床的利用率只有30%。如果能通过一个数据平台，把制造相关的各种信息统一起来，数据能够无缝地进行交换，数控设备的利用率可以提高到70%～80%。 一、概述 现代的制造车间以数控机床为主，配置各种CAD/CAM、PDM和ERP系统，由于各系统之间相互独立，导致数据无法交换，形成信息孤岛，数据需要重复输入现象严重，信息沟通多通过纸质文件进行，效率低下，而且制造文件的版本控制难以实现。据统计，制造车间NC机床的利用率只有30%。如果能通过一个数据平台，把制造相关的各种信息统一起来，数据能够无缝地进行交换，数控设备的利用率可以提高到70%～80%。 针对以上问题，由Spring公司开发的数控刀具管理系统ToolExpert拥有一套成熟的解决方案。例如，用户企业可能拥有至少5台数控加工中心，在机械加工过程中存在下列问题：车间操作员将20%时间花在了切削刀具上;16%的生产计划因为缺少合适的刀具而停止;40%~80%的管理时间浪费在无效的刀具搜索;30%~60%的刀具库存没有被有效地管理等。而在生产车间，一切环节都围绕着机械加工流程展开，如何实现与机械加工各环节的信息化自动管理，成为缩短加工工时与提高生产能力的关键。ToolExpert作为一个数据平台，集成车间现有系统，从工艺编程开始，涉及了整个生产流程，包括计划排产、刀具库房管理、对刀仪数据接口、机床程序传输与监控、机床卸载刀具、刀具报废或修磨处理、刀具消耗统计以及刀具采购与订单接收管理。该系统采用C/S结构，客户端只需一次安装，后期的更新与维护在server端完成，维护简单方便。在sever安装有核心数据库，用于管理生产相关数据。 在数控车间内，通过基础核心数据库，对刀具相关部件、量具、夹具和程序等信息进行管理，集成CAD/CAM、PDM和ERP等系统，数据通过ToolExpert平台进行无缝传输，共享信息，提高及时性，避免了重复数据输入。ToolExpert负责管理以刀具为核心的整个生产过程，包括工艺编程、刀具查找、库房管理(刀具、夹具和量具)、理论装配与物理装配、计划排产、车间备刀、上传/卸载程序、刀具消耗分类统计、刀具使用预测以及采购申请与接收订单。 ToolExpert的设计理念是帮助用户实现生产工艺和生产线的全面自动化管理。优化工艺，监控和管理数字化车间的所有活动，基本功能模块包括：工艺;车间准备;CNC机床准备;库存管理/分析。ToolExpert负责管理所有与刀具相关的工作流程，ToolExpert的功能模块如图1所示。
高效的刀具管理软件解决方案ToolExpert 现代的制造车间以数控机床为主，配置各种CAD/CAM、PDM和ERP系统，由于各系统之间相互独立，导致数据无法交换，形成信息孤岛，数据需要重复输入现象严重，信息沟通多通过纸质文件进行，效率低下，而且制造文件的版本控制难以实现。据统计，制造车间NC机床的利用率只有30%。如果能通过一个数据平台，把制造相关的各种信息统一起来，数据能够无缝地进行交换，数控设备的利用率可以提高到70%～80%。 一、概述 现代的制造车间以数控机床为主，配置各种CAD/CAM、PDM和ERP系统，由于各系统之间相互独立，导致数据无法交换，形成信息孤岛，数据需要重复输入现象严重，信息沟通多通过纸质文件进行，效率低下，而且制造文件的版本控制难以实现。据统计，制造车间NC机床的利用率只有30%。如果能通过一个数据平台，把制造相关的各种信息统一起来，数据能够无缝地进行交换，数控设备的利用率可以提高到70%～80%。 针对以上问题，由Spring公司开发的数控刀具管理系统ToolExpert拥有一套成熟的解决方案。例如，用户企业可能拥有至少5台数控加工中心，在机械加工过程中存在下列问题：车间操作员将20%时间花在了切削刀具上;16%的生产计划因为缺少合适的刀具而停止;40%~80%的管理时间浪费在无效的刀具搜索;30% ~60%的刀具库存没有被有效地管理等。而在生产车间，一切环节都围绕着机械加工流程展开，如何实现与机械加工各环节的信息化自动管理，成为缩短加工工时与提高生产能力的关键。ToolExpert作为一个数据平台，集成车间现有系统，从工艺编程开始，涉及了整个生产流程，包括计划排产、刀具库房管理、对刀仪数据接口、机床程序传输与监控、机床卸载刀具、刀具报废或修磨处理、刀具消耗统计以及刀具采购与订单接收管理。该系统采用C/S结构，客户端只需一次安装，后期的更新与维护在server端完成，维护简单方便。在sever安装有核心数据库，用于管理生产相关数据。 在数控车间内，通过基础核心数据库，对刀具相关部件、量具、夹具和程序等信息进行管理，集成C AD/CAM、PDM和ERP等系统，数据通过ToolExpert平台进行无缝传输，共享信息，提高及时性，避免了重复数据输入。ToolExpert负责管理以刀具为核心的整个生产过程，包括工艺编程、刀具查找、库房管理(刀具、夹具和量具)、理论装配与物理装配、计划排产、车间备刀、上传/卸载程序、刀具消耗分类统计、刀具使用预测以及采购申请与接收订单。 ToolExpert的设计理念是帮助用户实现生产工艺和生产线的全面自动化管理。优化工艺，监控和管理数字化车间的所有活动，基本功能模块包括：工艺;车间准备;CNC机床准备;库存管理/分析。ToolExpert 负责管理所有与刀具相关的工作流程，ToolExpert的功能模块如图1所示。
机械工程师 MECHANICAL ENGINEER 2017年第12期网址：https://www.doczj.com/doc/6a6705224.html, 电邮：hrbengineer@https://www.doczj.com/doc/6a6705224.html, 刀具管理系统的设计 周洪燕，宿文玲，于海宏 （哈尔滨量具刃具集团有限责任公司， 哈尔滨150040）摘要：介绍了一套刀具管理系统，具有完善的刀具数据库管理功能， 能够灵活、高效地对不同生产厂家、不同类型的刀具进行库房管理，具有丰富的库存统计功能，可以满足用户对刀具管理的各种需求， 显著地提高机床的利用率，提高智能化管理水平。关键词：刀具；管理；智能化中图分类号：TP 311.52 文献标志码：A 文章编号：1002-2333（2017）12-0126-04Design of Tool Manager System ZHOU Hongyan ，杂哉Wenling, YU Haihong (Harbin Measuring &Cutting Tool Group Co.,Ltd.,Harbin 150040,China) Abstract 院This paper introduces a kind of tool manager system.It has perfect tool database manage function.It can manage different type of tools from different manufacturers.It has stock statistics function.It can satisfy user's any requirements for Tool manage,improve use ratio of machine and intelligent manage level. Keywords:tool;manager;intelligent 0引言 随着现代工业的发展，人工成本的急剧增加，精细化管理越来越引起人们的重视。 据统计，在众多的制造企业的生产过程中，间接的刀具费用占制造成本的30%。16%的计划作业停止是由于缺乏刀具造成的，30%~60%的刀具库存不在控制之中，20%的机械师时间花在查找刀具上，40%~80%的监督人员时间花费在寻找合适刀具上。由此可以看出，刀具管理在现代加工企业的生产现场管理工作中所占的比重非常大。刀具管理部分成了制约企业加工能力的瓶颈，那么刀具管理系统的开发势在必然。 近年来,刀具管理软件已经越来越引起众多大企业的重视,许多大企业也相继开发了自己的刀具管理软件,主要有英国CTMS 公司、 美国Cincinnati Milacron 公司、德国的Zoller 公司、瑞典的Sandvik 公司。国外的刀具管理软件功能都很完善，而且各有其优势，但是价格高昂，难以被大多数企业接受。目前，国内刀具管理系统的研究起步比较晚，现有的刀具管理软件产品，绝大多数由企业和科研院所根据企业的实际需求编制，主要目的是实现刀具信息的计算机管理，功能单一，大部分只是着眼于刀具管理系统的某一方面，主要解决刀具的库存管理以及借入、借出等简单的动态管理。 Kelch 公司是哈量的全资子公司，主要生产两大类产 品：刀柄和刀调仪，刀柄是用来装卡刀具的，刀调仪是用来测量刀具参数的， 应该说Kelch 公司的产品和刀具具有完全的相关性。在销售刀柄和刀调仪的过程中，客户也提出了购买刀具管理软件的需求，甚至于将订单和刀具管 理软件进行绑定，因此，开发具有我公司自主知识产权的刀具管理软件也是我公司的重要发展战略。 此套刀具管理系统是一款根据我公司对刀具管理的实际需求自主开发的专业的刀具管理系统，用智能的管 理系统来取代传统的落后的人工管理方式，显著提高刀具的管理水平。本系统着力于刀具的库存管理、刀具的2D/3D 模型管理、造型管理、加工方案制定等功能， 集合各家刀具管理软件的优点，其软件的起点是国际先进水平。此刀具管理软件系统发布版本目前已经完成，是一套比较成熟的刀具管理软件，对刀具的使用、存储进行管理，能够满足生产和使用厂家及经销商目前的迫切需求，打通目前企业中刀具管理制约加工能力的瓶颈，降低刀具管理成本及人工成本，大大增强企业的核心竞争力。1 刀具管理系统的主要功能模块 VS2012是微软公司推出的开发环境。是目前最流行 的Windows 应用程序开发环境。C#是微软为.NET Framework 量身订做的程序语言，C#拥有C/C++的强大功 能以及Visual Basic 简易使用的特性，并且面向对象的设计思想也是最强大的。是目前可视化和面向对象最强大的开发工具。 本软件采用VS2012作为开发平台，C#作为开发语言，Access 作为数据库开发工具，EDrawing2008插件作为TooIM 刀具管理系统工具管理制造管理 基础数据辅助功能工具管刀具管加工方使用记库存管用户管设备管供 应商管仓库管数据库联组件导打印输基金项目：国家重大科技专项 （2015ZX04005-008）126
《IT项目管理》复习要点 第一章 项目： 项目包含以下含义： 项目是一项有待完成的任务，有特定的环境与要求。 项目必须在一定的组织机构内，利用有限的资源（人力、物力、财力等）在规定的时间内完成任务。 项目任务要满足一定性能、质量、数量、技术指标等要求。 IT项目的定义： 以信息技术为基础的项目。它是项目管理的一种特殊形式，随着信息技术的发展而诞生并不断完善的一种新的项目管理。 IT项目产生的根源来自市场的需求。电子商务、企业信息化、电子政务等工作产生了以信息技术为基础的项目，即IT项目。 IT项目的主要类型：计算机、通信及微电子技术研发；网络系统集成；软件开发；企业信息化、商务电子化、医疗远程化等各领域IT应用；IT咨询与服务。 项目是在一定的时间、资源、环境等约束条件下，为了达到特定的目标所做的一次性任务或努力。 什么是IT项目管理：IT项目管理是以信息技术为基础的项目管理，是项目管理的特殊形式，是随着信息技术的发展而诞生并不断完善的一种新的项目管理。 特性； IT项目的特性：(1)目标不准确(2)需求多变(3)功能渐进(4)时间不准确(5)风险不确定(6)智力劳动密集 IT项目具有项目管理的共性 项目的特征 1．一次性；这是项目最主要的特征。 2．独特性； 3．目的性； 4．整体性； 5．制约性。 项目工作与职能部门工作的区别； 项目工作：一次性的、独特的、有特殊目的、项目经理负责、跨部门协同合作。 职能部门工作：重复性的、标准的、按一般计划目标、部门经理负责、本部门单一操作。项目生命周期划分及各阶段特点； 任何一个项目，都包括以下5个项目管理过程 启动过程：确定一个阶段可以开始； 计划过程：进行计划并且保持一份可操作的进行安排，确保实现阶段的既定目标； 执行过程：协调人力和其他资源，执行计划； 控制过程：通过监督和检测过程确保阶段达到目标，必要时采取一些修正措施； 收尾过程：完成阶段的交付物并且有序地结束该阶段。
《交通规划》课程教学大纲 课程编号：E13D3330 课程中文名称：交通规划 课程英文名称：Transportation Planning 开课学期：秋季 学分/学时：2学分/32学时 先修课程：管理运筹学，概率与数理统计，交通工程学 建议后续课程：城市规划，交通管理与控制 适用专业/开课对象：交通运输类专业/3年级本科生 团队负责人：唐铁桥责任教授：执笔人：唐铁桥核准院长： 一、课程的性质、目的和任务 本课程授课对象为交通工程专业本科生，是该专业学生的必修专业课。通过本课程的学习，应该掌握交通规划的基础知识、常用方法与模型。课程具体内容包括：交通规划问题分析的一般方法，建模理论，交通规划过程与发展历史，交通调查、出行产生、分布、方式划分与交通分配的理论与技术实践，交通网络平衡与网络设计理论等，从而在交通规划与政策方面掌握宽广的知识和实际的操作技能。 本课程是一间理论和实践意义均很强的课程，课堂讲授要尽量做到理论联系实际，模型及其求解尽量结合实例，深入浅出，使学生掌握将交通规划模型应用于实际的基本方法。此外，考虑到西方在该领域内的研究水平，讲授时要多参考国外相关研究成果，多介绍专业术语的英文表达方法以及相关外文刊物。课程主要培养学生交通规划的基本知识、能力和技能。 二、课程内容、基本要求及学时分配 各章内容、要点、学时分配。适当详细，每章有一段描述。 第一章绪论（2学时） 1. 交通规划的基本概念、分类、内容、过程、发展历史、及研究展望。 2. 交通规划的基本概念、重要性、内容、过程、发展历史以及交通规划中存在的问题等。
第二章交通调查与数据分析（4学时） 1. 交通调查的概要、目的、作用和内容等；流量、密度和速度调查；交通延误和OD调查；交通调查抽样；交通调查新技术。 2. 交通中的基本概念，交通流量、速度和密度的调查方法，调查问卷设计与实施，调查抽样，调查结果的统计处理等。 第三章交通需求预测（4学时） 1. 交通发生与吸引的概念；出行率调查；发生与吸引交通量的预测；生成交通量预测、发生与吸引交通量预测。 2. 掌握交通分布的概念；分布交通量预测；分布交通量的概念，增长系数法及其算法。 3. 交通方式划分的概念；交通方式划分过程；交通方式划分模型。 第四章道路交通网络分析（4学时） 1. 交通网络计算机表示方法、邻接矩阵等 2. 交通阻抗函数、交叉口延误等。 第五章城市综合交通规划（2学时） 1. 综合交通规划的任务、内容；城市发展战略规划的基本内容和步骤 2. 城市中长期交通体系规划的内容、目标以及城市近期治理规划的目标与内容 第六章城市道路网规划（2学时） 城市路网、交叉口、横断面规划及评价方法。 第七章城市公共交通规划（2学时） 城市公共交通规划目标任务、规划方法、原则及技术指标。 第八章停车设施规划（2学时） 停车差设施规划目标、流程、方法和原则。 第九章城市交通管理规划（2学时） 城市交通管理规划目标、管理模式和管理策略。 第十章公路网规划（2学时） 公路网交通调查与需求预测、方案设计与优化。 第十一章交通规划的综合评价方法（2学时） 1. 交通综合评价的地位、作用及评价流程和指标。 2. 几种常见的评价方法。 第十二章案例教学（2学时）