系统工程具体是做什么的？

系统工程具体是做什么的？

更新2024

这篇文章写于很多年前，这些年系统工程发展的很快，国内的发展也很快，这是好的一面，但是也存在一些问题。一个主要的问题就是恒大化，重造门胜于打地基，重PPT胜于做设计，重销售胜于技术，重预售胜于交付。

更新2020

系统工程之大局观：写点关于系统工程大局观的东西，在一个大型研发项目中，系统工程处于什么地位，在各个阶段主要做什么，与其它部分的关系是什么。不同领域有不同的研发过程标准，这里仅举美国DoD的例子，DoD的系统范围比较广，从复杂的航母到简单的枪支都有，不像NASA那样比较单一，便于不同行业的人理解；DoD也比较强势，能够整合三军的标准，整个研发过程各个标准协调一致性很好；DoD有两张教学挂图（就是下面两张），非常完整地展示了整个武器系统采购中各个系统之间的关系。在这两张图上，横轴代表研发阶段，分为：装备方案分析阶段（目标是选择满足能力需求的方案，主要活动是执行多方案分析），技术成熟和风险规避（目标是技术成熟减少风险，主要活动是竞争样机）、工程研制（目标是生产的设计，证明产品是可生产的，活动是详细设计和系统演示） 、生产部署（目的是证明生产线并生产和部署系统，活动是生产、初始作战使用评估和部署）和使用保障阶段，生产部署和使用保障有所重叠。纵轴是各个系统，包括三大块，第一是JCID(联合能力整合与开发系统），这个系统是分析需求的，最初美国国防是基于威胁来采购产品，后来经过改革是基于国家战略来采购能力，能力可以是非装备的，例如通过改装现役装备或者培训部队来达到某种能力；第二块是PPBE(计划和预算执行系统)，这个系统是管钱的；第三块是DAS(国防采购系统)，这里面有项目管理、签合同、系统工程、软件、试验和评估、生产、后勤保障等，国防采购系统的主要产品包括AoA（多方案分析）、装备方案、Prototypes（样机）以及产品；在方案分析阶段，系统工程的主要任务是分析需求、规定性能指标、评估可选方案，在技术成熟和风险规避阶段，系统工程的主要任务是对成本性能进行权衡、计划技术方法、管理技术风险、建立系统架构，在工程研制阶段，系统工程的主要任务是最终定稿设计和制造规范、策划小批量生产，之后的阶段主要任务是评估生产准备状态、评估系统功能、改进系统等。以上三个系统的驱动方式不同，JCID是需求驱动，PPBE是时间驱动，DAS是事件（评审、产品的交付等事件）驱动。

有很多人问有哪些系统工程专业大学可以选，转个地址吧：https://www.incose.org/academic-affairs-and-careers/se-education/world-wide-programs。里面有个下载文件，可以查。

------------------------------------------------------------------------------------------

更新201808

写一个影响了世界的系统工程项目：Semi-Automatic Ground Environment (SAGE)，翻译过来叫半自动地面环境。这个项目为计算机时代和互联网时代奠定了基础。在第二次世界大战的时候，英国在伟大的不列颠空战中利用一项全新的技术：雷达取得了胜利，当时各个雷达站收集的信息被汇总到指挥中心，由操作员观察敌军的动向，并指挥迎击，但当时的信息有5min延迟，对于第二次世界大战的飞机还够用，但到了冷战时期，美国面临苏联的战略轰炸机的危险，这个延迟就太大了，为此美国国防部授权空军去改进防空系统，而美国空军又找到了麻省理工去做这个事情。当时的假设情景是苏联的战略轰炸机会从高空过来，然后在最后一段航程潜入低空，由于水平线的限制，地面雷达很难发现目标（当时还没有空中雷达），而且当时雷达站之间用无线电通讯，会被核打击的脉冲电磁波干扰。为此，MIT列出了两个核心问题： 第一，要能将各个雷达站的数据传输到中央计算机；第二，要有可以实时分析数据的计算机。今天看起来这两个问题很好解决，但当时是1950年，既没有互联网，也没有计算机。当时的美国空军一个实验室开发了一个将雷达模拟信号转换成数字编码的早期形式的调制解调器，而MIT的伺服机构实验室也为飞行仿真开发过一个计算机，但这个计算机仅仅有5个字的RAM和27个字ROM，还不如我们现在最简单的手持计算器，为此MIT成立一个数字计算机实验室开发了磁芯存储器。这个项目的成本超过了原子弹的曼哈顿项目。有趣的是，这个项目由于苏联搞了战略导弹，其在军事上作用有限，但这个项目的成果包括存储器、调制解调器、软件工程却对世界产生了革命影响，通过这个项目成长起来的IBM在1954去搞一个微缩版的SAGE系统，叫作半自动业务相关环境SABRE，用于航空订票系统（应该是我们的12306的祖先吧），最后从一个制表器公司成为世界计算机行业巨头；MIT林肯实验室成为美国雷达科技最先进的研发中心 ；兰德公司的一个系统工程部门“系统开发公司”为SAGE开发软件，后来推动了软件工程和信息技术的发展 。

--------------------------------------------------------------------------------------------

更新，写一个涉及验证、软件工程和控制工程、可靠性、故障追踪方面的例子。那是在很多年以前，刚参加工作不久，当时碰到一个产品，交付后可靠性很低。先介绍一下这个产品的背景，这是个控制系统，采用一种类似脉冲调宽PWM控制方法，也就是说控制器送给执行器的不是个比例信号，而是个脉冲，经典PWM仅仅调制脉冲宽度，而我们更复杂，还要调制脉冲的中心，其原理就是计算机根据所需控制量大小生成脉冲上升沿和下降沿，最早用模拟电路做，后来用软件实现，当时还是汇编。学过控制的大概都清楚，大学里面通常学得都是周期性线性控制，至于脉冲调制控制，很少学到，在这个系统中脉冲边沿的生成与控制解算周期是异步执行的，控制专业对这个异步执行的行为缺少 认知，而软件编码的人对异步执行中的数据更新也缺少理解，这就埋下了小强滋生的土壤。有一次一个很明显的故障引起了我的注意，表现为脉冲的边沿不准确，但这个现象很随机，很难抓住。一般来说，验证一个控制器是否准确，有两种方法，一种是给产品加一个输入，测量这个产品的输出，用记录下的输入在仿真程序里面跑一下，得到一个标准输出，再将标准输出和实际输出对比，就可以直观的看出是否超差；第二 种是提供一个标准输入，预先计算出标准输出，再选择几个典型时刻比对标准输出和实际输出。两种方法我们都用到了。但如前所述，这是脉冲调制控制，不像比例关系那么直接，另外由于控制专业对脉冲的生成所采用的异步机制缺少认知，也没有仿真脉冲生成的过程，仅仿真到脉冲生成的前端，因此，第一种方法不知道脉冲生成有没有问题；第二种方法虽然发现了有时候脉冲生成的不准确，但由于其很随机，通常大家都将其作为随机输入噪声引起的，为此验收时还有意放宽了标准。我发现了几个脉冲不准确后，对此有所怀疑，于是想到了一个验证方法： 统计。虽然噪声可能引起个别误差，但当统计样本量足够多时候，误差的平均值应该趋于0，这一统计不得了，发现了脉冲生成有一个系统性延迟，而且这个延迟有一个很大散布。然后，对历史数据做了个回顾，一直回顾到很多年前研制阶段的某个时间点，在这个时间点前没有系统延迟，在这个时间点上，控制对象的运动出现了系统偏差，当时请了很多专家分析，最后原因不清楚，没有人想到是控制器本身输出不正确，后来控制专业在算法做了补偿算是将 这个问题解决了，但是他们没想到的是算法虽然能够补偿系统延迟，但无法补偿随机散布。这个随机散布引起了后面一系列可靠性问题并持续数年之久。当我得出是控制器本身出问题的结论后，编软件的人开始查软件，最后发现其内部中断设置有错误。最终进行了软件升级，消除了系统延迟，取消了控制补偿，算是解决了问题。这个故事说明了几个重要的事： 1. 细心。2. 验证方法设计。3. 出现故障时仅仅有解决措施不行，还要机理清楚。----------------------------------------更新，搬运一个洛克西德马丁公司的系统工程职位说明，国内是不会这么详细的说明的，注意它们的系统工程职位下有很多种，这只是其中一个：

要求ID:245519BR工业职位标题：系统工程职位编码: E1463职位描述：有经验的工程师，需要开发动态系统、制导和导航系统，通过采用多变量控制和估计理论的载体控制的数学模型和计算机仿真。经验最好包括交叉学科工程知识、技能集合和经验，例如控制工程、系统工程、系统集成，嵌入式软件和/或水下载体的制导导航和控制。必须具有对控制系统深度了解。工程师将参与所有项目阶段-方案、设计、研制和测试。该工程师将：-采用控制理论原理和流体力学开发算法、控制架构和水下载体的解决方案；-展示应用经典和多变量控制和估计理论设计导航和控制系统的专业性，包括算法设计、实施和确认测试。-开发模型和仿真载体和控制子系统-展示对流体系统和/或机电作动的工作知识。-开发载体和控制子系统的模型和仿真。-定义和分析系统要求并准备方案设计。-开发和维护技术文档包含需求规范、接口控制规范、权衡研究、运行构想和测试文档-编写技术建议书并展示给用户-提供用户现场保障。基本条件：-很好的独立学习新技术和用户的领域。-能够连续工作在大量项目同时平衡优先级并满足用户期望。-卓越的口头和书写沟通能力。-客户接口经验。-使用DOORS,SYSML,Rhapsody和基于模型的系统工程经验。-跟踪和终结测试不正常的经验。-设计和测试发电设备的经验。-设计和测试电力基础设施的经验。期望的技能：-水下系统经验-系统架构设计和分析的知识-能够执行系统权衡-能够领导多学科设计团队-能够获得保密资格业务领域：-任务系统和培训部门：-Q538,系统工程职业类别：系统工程需求开发工作时间表：弹性非标准40小时每周

------------------------------------------------------------------------------------------------更新，写一些实际工作过程中具体事例和经验以便于大家更清楚了解系统工程师的工作，先写一个解决方案的例子，这是系统工程最核心最具创造性的部分。有一个产品为了增加运动控制稳定性，增加了一个阻尼控制回路，使用了一个速度传感器，这个速度传感器本身并不是什么新技术，阻尼控制理论也非常成熟，但被控对象有点特殊，速度传感器安装到被控对象上产生了极大的误差，这个误差大到淹没了有用信号，这个误差与结构上的安装位置和角度有着确定的关系，从理论上我们只要知道非常精确安装位置和角度就可以消除误差。但糟糕的是我们无法达到所要求的精度。结构误差有两部分组成，一部分来自于传感器本身的加工，一部分来自于被控对象，传感器本身加工误差可以在安装前标定好，但被控对象的结构误差就没法标定，甚至在被控对象工作过程中这个误差还会变。这个问题开始涉及三个专业，控制、机械结构和传感器，控制的阻尼控制器已经是最优了，机械结构误差也已经控制到最小了，传感器的自身加工误差也已经标定消除了，但是系统性能就是无法满足要求。那么怎么解决这个问题？在大学的时候，理工科的一般都学过线性代数最小二乘法，使用最小二乘法我们可以通过已知输入、输出辨识出未知参数，碰巧的是，这个案例中被控对象工作初始几百ms内会有一个已知运动过程，通过这个过程我们可以辨识出误差影响系数进而用于之后的误差消除，但这里面有个难点，虽然我知道可以很容易离线用最小二乘法辨识这个参数，但这个案例中控制系统不允许你停下来，也就是必须由控制计算机在线辨识，由于处理资源和存储资源的限制，这个在线辨识还必须是迭代算法，迭代最小二乘法可不是大学基础课，但好在有网络，我可以搜索到迭代最小二乘法，然后现学现卖。好的，现在算法的原型做出来，我们已经没时间和成本去冒风险了，必须确保万无一失，必须确保在各种情况下这个算法都能正确运行。在过去我们积累了大量实际运行数据，通过将实际数据代入到算法中仿真得到的结果很好，并且加入其它误差因素做敏感性分析精度也比以前好。这时候可以进入实施阶段了，也就是用嵌入式代码实现这个算法，但糟糕的是做嵌入式编程的人不太懂如何把迭代最小二乘法中矩阵运算编成C代码，以至于编出来的软件bug一堆。好在我线性代数和C语言都还不错，于是又帮着软件程序员解决了代码中错误。最终这个方法投入系统中运行很好，即提高了精度又减少了标定成本。回顾一下案例，解决这个问题的作为系统工程师所使用的能力： 1. 具有大学基础数学知识，知道最小二乘法；2. 知道传感器的误差模型； 3. 知道被控对象在初始有一个确定运动过程；4. 知道控制系统工作时序。5. 知道结构精度已经达到极限；6. 能够综合以上传造性想到在线辨识误差系数。7. 能够利用网络现学现卖。8. 能够积累历史数据并利用这些数据做原理验证。9.能够在出现瓶颈时补漏（例如程序员不会编矩阵运算）。

-------------------------------------------------------------------------------------------------------------------系统工程是一门非常前沿专业，在美国系统工程师是最热门的职业，在中国虽然很多人放在嘴上，但实际上很少有人这是个什么职业？有人甚至说这是个当总统的专业，简直是在侮辱系统工程师。系统工程最初起源于航天、航空、军事部门，由于卫星、飞船、飞机、导弹这些产品的研发需要很多专业的综合，所以诞生了系统工程；后来该专业也扩展到民用部门，包括民用航空、铁路系统、通信系统、医疗设备等，甚至是一个小小的照相机也涉及系统工程。中国最初提出系统工程就我所知大概是钱老了，但是从他的系统工程概念还不算太成熟，主要偏重于管理，而实际上系统工程跨越了技术和技术管理，它与项目管理有所交叉，也有很大的区分。以下是一个系统工程师的在项目开发中的所做的事情：第一步，你要去研究市场，了解用户有什么问题、想要些什么，有可能在市场上你已经有竞争对手，你还要调查对手的当前状态，最后你要为用户提出建议的解决方案，开发一个新的系统或是改造一个旧的系统。这时候你的系统可能仅仅是一个设想，你的系统可能很庞大，需要大量的资金投入，潜藏着许多技术风险，而企业的未来就依赖于你的专业决策，这时候一方面你需要尽量满足用户的欲望，又要小心地避免不可逾越的技术障碍。如果你的系统是卫星、飞机这样庞大的系统，一般的专业工程师如机械工程师、电子工程师根本无法完成这样的工作，这时候你才会闪亮登场。你要与用户签订合同，包括资金、进度、技术等方面的内容，系统的开发被划分为若干的阶段，资金分阶段的支付，每个阶段有确定的进入和完成准则，以避免潜在的风险。作为专业系统工程师，基本的能力包括技术规范编写、进度规划、分解工作是需要的，作为国内系统工程师（如果存在这个名词的话），尤为重要的是喝酒、吹牛皮、胆大妄为和玩弄词汇的能力。一个需求分析的失败案例：曾经有一位工程师，他提出一个几乎是天才的创意，用卫星连接全世界通信，这个工程具有系统工程的特质，要发射６６颗卫星，投资ＸＸ亿美元，但不幸的是，这个项目失败了。首先手机的发展很快占据了市场，其次卫星电话面临技术障碍，无法在室内通讯，而且硬件过于庞大。可以说项目的决策者没有系统的分析用户的需求、技术风险和竞争对手，导致项目的失败。这就是摩托罗拉的铱星计划。第二步，你要提出解决方案，或者叫设计，对系统来说也可以叫架构开发。虽然是第二步，但并不说设计就一定在用户需求调查之后，为了占领市场，有时候它在需求调查之前就开始，有时候它随着需求分析同步进行。系统工程师在这个阶段要开发架构。什么是架构，这个词来自于最古老的工程行业-建筑业，风行于最现代的工程行业-软件业。打个比方，架构就好比人的骨架，潘长江就是吃的再多也长不成姚明，因为他们骨架不同。架构设计充满创意，系统工程师当深通于此，产品围绕架构组成系统。架构使用视图来表达，机械工程使用三个图表示三维实体，系统工程师则使用多个架构视图描述系统。好的架构就像金字塔一样悠久，坏的架构就像某些豆腐渣工程一样脆弱。作为专业的系统工程师，基本的能力包括系统建模、仿真和分析技术。一个架构设计的失败案例：在某国一个雷电交加的夜晚，两车相撞了，在经历了５个月的调查后，事故报告公开，造成事故一条设计原因是，当一个采集设备被雷击故障后，传送给主机的状态信息一直保持为故障前采集到的信息，使人做出错误的判断。在不知道情况的时候保持最后的状态似乎是一个非常自然的选择，很多的设计师都非常习惯这样设计，但真的如此吗？这个系统的设计师是否做过“故障模式影响分析”ＦＭＥＣＡ不得而知，在项目中做ＦＭＥＣＡ是非常吃力不讨好的，因为这首先要假设所有的设备都可能出故障，然后通过设计确保故障不影响安全，一些安全关键系统中要求连续两个故障或者两个操作错误或者两个操作错误和故障的组合不会导致致命事故。管理相关：系统工程师脚踏两只船，一只是技术，一只是管理，因此常常与项目管理者的职责分配剪不断理还乱，通常来说项目管理者侧重于进度、资金、范围等，而系统工程师侧重于技术管理，包括技术状态、接口、需求等，什么？技术还有管理？是的，技术需要管理。系统工程师要像猎狗追踪每一个要求的落实，从最初的用户要求到向部件提出的要求直至获得明确无误的证据表明需求已经落实，否则部件设计师会像系统工程师欺骗用户一样欺骗系统工程师。曾经一个火星探测器坠毁，仅仅因为计算单位不统一，如果你是一个学生，计算单位错误最糟糕的结果是考试不及格，而在大型工程中就是数亿美元的损失，为此系统工程师要紧盯每一个接口，防止彼此设计的不匹配，这是一项非常繁琐的工作，因为一个大型系统的接口从几百到几千几万。需求也罢、接口也罢，都要有秩序的管理。管理的技能是必需的。验证：验证就是为产品满足需求提供证据的活动。如果没有验证，系统的开发就会像中国的保健品市场一样混乱。验证包含了检查、分析、演示、测试几个类别，验证也像需求一样划分为多个层次，从底层部件到最顶层的系统需要逐步的验证，验证是一项非常消耗资源的活动，因此系统工程师当小心的选择验证的类别、层次，以平衡进度、风险和成本。验证中的某些活动甚至需要独立的专业和工程师支持，例如试验工程师，因为测试设备的准备、开发并非系统工程师能够完成的。对于验证活动而言，除了数学分析能力、发现问题的能力外，最大需要可能就是勇气和诚实，因为在验证活动中发现问题后，许多工程师由于面临各种压力或是采用鸵鸟政策视而不见或是伪造数据欺骗用户。

权衡研究： 系统的目标往往是互相冲突的，无法同时满足所有要求，例如性能和成本，为了需要更规范的方法对多个方案进行权衡，包括确定目标，确定目标权重，评估每个方案的目标分值，系统设计者往往很容易先入为主的掉到单一方案中不能自拔，所以需要一个权衡研究过程，以更客观更开放的思维评估方案。

------------------------------

目前有很多标准对系统工程工作内容有很详细的定义，例如INCOSE、美国国防部、海陆空三军、ISO、CMMI、NASA等都有各自标准，这些标准定义的内容大同小异，一般包括：需求分析、架构设计、权衡研究、验证、技术状态管理等等。国外曾经对系统工程与绩效的相关性做一个研究，其中系统架构设计和系统需求分析是最重要的，其他重要的还权衡研究、验证等。