剑思庭，软件工程硕士，曾开发过各种厂商dcs和plc系统及智能仪表相对应的opcserver软件包；曾利用s7300/400系统开发过多个行业工艺控制系统；曾用SIMATIC IT技术为化工厂开发过MES管理系统和生产调度指挥系统；曾利用WINCC开发过在线设备管理系统；并获得过多项技术认证，例如Profibus总线认证、Controllogix产品认证等等。今天将用一些简单易懂的词语，带大家来认识工控，了解什么是现场总线，组态软件的构造，SFC的含义，冗余和热备的区别。
白话用户需求的重要性
说到用户需求是什么呢，通俗地说就是自控项目中客户想要达到的效果和东西。而专业上来说，也就是客户对自控系统提出的自己的要求标准，这个要求标准根据自己的使用目的、工艺、用途等可以提出自己的要求。自控集成商依据客户的需求进行自控设计（或确认自己已经完成设计的项目能符合需方的要求）。 作为自控工程师在做项目之前这是过程是一定要洗礼的，弄清楚客户想要干什么和结果，是自控工程师首要任务。大家该说这还不简单！人家要什么我们就给人家编什么，其实不然不要小看了这个过程，十分重要，它是一个项目的龙头，如果它出了偏差后面设计和执行再正确也是枉然。在现实情况中我们会发现存在这样一种情况，那就是一个自控工程师在现场把在家里写的程序全部推翻在现场重新写了一份，实在让人感叹技术劳动力的脆弱。 其实很多自控项目虽说没有一个到了现场不改变的但是也绝不会出现全部重写的现象。这是为什么呢，其实这就是需求分析没有分析透彻，客户一般都是从事工艺设计和生产的，他们并不是直接了解自控的系统，即使说出来他所能知道同一个自控名词也有可能表达不同结果。同样名字不同的地域就会出现不同的结果，同理在自控项目中工艺认为的一个自控词语概念并非我们理解的概念，况且就是同一个专业还会出现不同的理解方式。 那需求该如何做呢？说简单很简单，说不简单也很难。你需要把客户的工艺思想挖掘出来，而变成自控行业能够理解的要求。按道理来说用户提出来的需求应该是系统的，也就是我们能够看懂的，但是往往这只是一种理想，要知道客户是我们的衣食父母，客户很多招标书都是由系统集成商来写的，所以现实情况很残酷。客户可能不能跟你说清楚他的需求，这个时候你就需要按照客户提供的只言片语，慢慢勾勒出来一个他想要的自控系统轮廓，经常会出现类似《开心辞典》一样情形，我们提出问题后列举四种方式或者情况，然后业主选择和他最接近的那一种。我个人理解一定要在需求阶段把用户的需求细化到极致，这样可以很方便躲避项目中技术难题（给不能实现或者不好实现的技术难题消灭在萌芽状态）和给验收和尾款带来顺利之门。在举个例子，用户在需求中会提出来要当工艺参数超限要声光报警，就是这么简单的一句话，这里边变化很大。工艺超限，大家都可以理解，就是PV大于或者小于了ALARM这个时候就要产生报警，但是声光报警的方式太多了，上位机可以发出报警声音、组态画面可以动态闪烁报警信息、控制机柜DO可以驱动报警器发出声音和LED灯的报警指示。这就牵扯到两种不同设计和实现方式，虽然不会牵扯太多的费用但是一旦采用了前者方式在改成后者，就需要硬件上有些变动，这都是大家（我们和业主）不愿意看到的。所以很有必要在用户需求的文件上附加上技术需求附件（双方签字有效的），这样可以让你在项目实施中不会处于来回变动当中。 以下我将share我在日常当中所用的部分用户需求文档模板供大家参考（这个模板是我做工程的时候保留下来其中一种），这里以SCADA系统为例。由于文字较多我只列出来文档目录和描述，如果大家需要详细模板可以向我来函索要！（QQ ：79867128 Email：jiansiting@gmail.com）
REVISION HISTORY 5
1.0 INTRODUCTION 6
1.1. PURPOSE 6
1.2. ORIGIN AND CONTEXT 6
1.3. SCOPE 7
1.4. DOCUMENT ORGANIZATION 8
2.0 OVERVIEW 9
2.1. BACKGROUND 9
2.1.1. Project Overview 9
2.1.2. Facility Overview 10
2.1.3. Automation Overview 12
2.2. GENERAL SYSTEM FUNCTIONS 14
2.3. SIMULATION SYSTEM 14
2.4. EXCLUSIONS AND FUTURE CONSIDERATIONS 14
3.0 OPERATIONAL REQUIREMENTS 16
3.1. FUNCTIONS 16
3.1.1. Process Monitoring 16
3.1.2. Alarm Management 17
3.1.3. Basic Control 19
3.1.4. Equipment Phase Control 23
3.1.5. Batch Management 24
3.1.6. Historical Data Collection and Retention 25
3.1.7. Other Monitoring and Control Features 26
3.1.8. Modes of Operation 26
3.1.9. Performance and Timing 28
3.1.10. Response to Failures 29
3.1.11. Security 30
3.1.12. Safety 30
3.2. DATA 31
3.2.1. Preliminary Data Definitions 31
3.2.2. Capacity Requirements 32
3.2.3. Access Speed 33
3.2.4. Archive Requirements 34
3.2.5. Data Security and Integrity 34
3.3. USER INTERFACES 36
3.3.1. General 36
3.3.2. Process Monitoring 40
3.3.3. Batch Management Interfaces 45
3.3.4. Alarm Management Interfaces 46
3.3.5. PCS Status Interface 48
3.3.6. Programming and Configuration Interfaces 49
3.3.7. Recipe Management Interface 49
3.3.8. Reports 5049
3.4. REMOTE PCS ACCESS 50
3.5. INTERFACES WITH OTHER SYSTEMS 50
3.5.1. Intelligent Process Interfaces 50
3.5.2. Other Process Control Systems 5150
3.5.3. Other Computerized Systems 5150
3.5.4. Shared Resources 51
3.6. ENVIRONMENT 51
3.6.1. Layout 51
3.6.2. Physical Conditions 5251
4.0 CONSTRAINTS 54
4.1. PROJECT CONSTRAINTS 54
4.1.1. Schedule 54
4.1.2. Procedural Constraints 54
4.2. COMPATIBILITY 55
4.2.1. Hardware Standards and Preferences 55
4.2.2. COTS Software Standards and Preferences 56
4.2.3. PCS Configuration and Integration Standards 57
4.2.4. PCS User Interface Standards 58
4.2.5. PCS Programming Standards 59
4.3. MAINTENANCE 60
5.0 LIFE-CYCLE 60
5.1. DEVELOPMENT 60
5.2. TESTING 60
5.3. DELIVERY 60
5.3.1. Documentation 60
5.4. SUPPORT 62
5.4.1. Start-up Support (list available options) 62
5.4.2. Post Start-up Support (list post-startup support available) 62
6.0 GLOSSARY 63
6.1. TERMINOLOGY 63
6.2. ACRONYMS 65
