嵌入式系统产品研发领域中的社会角色分工.pdf

《嵌入式系统产品研发领域中的社会角色分工.pdf》由会员分享，可在线阅读，更多相关《嵌入式系统产品研发领域中的社会角色分工.pdf（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 1 learning just as your favourite thing 嵌入式系统开发领域中的社会角色分工嵌入式系统开发领域中的社会角色分工（v1.0,18 Feb 2011）久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 2 目录目

2、录 目录.2 1.概论.3 2.软硬不分家.3 3.软硬件需求分析与系统架构师.3 4.硬件开发工程师.5 5.软件开发工程师.6 5.1.系统软件开发工程师.6 5.1.1.底层驱动开发工程师.6 5.1.2.应用软件运行平台搭建工程师.7 5.2.应用软件开发工程师.8 6.软硬件测试工程师.9 7.选择定位好你自己的角色.9 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 3 1.概论概论 如同其他的社会活动一样，嵌入式(linux)系

3、统开发领域中也有着不同的角色分工。假如你要进入这个行业，那最好先了解一下这个行业中的不同角色分工，然后根据自己的实际情况选择所感兴趣的角色，继而在每日的时间消耗过程中努力学习成为该角色所需要掌握的各种知识。在这篇文章里，我们以自身平时工作过程中的的实际经验为基础，来讨论开发领域中的不同角色分工。具体来说，在本文中，我们需要解决几大问题：在嵌入式系统产品开发领域中，到底会有哪些角色参与其中？这些角色是如何相互支持和协同工作来完成具体产品的？若要成为这些角色，分别都需要掌握些什么样的技能？上面这些问题当中，问三比较容易理解。对于问一，我们这里讨论的主要是那些参与具体产品开发的角色，对于那些管理类的

4、角色，咱们这里则忽略不谈。对于问二，我们关注的不是各角色之间交互的方式，而是关注于各角色在整个产品开发过程中各自要完成什么样的职能。(1)在继续往下看之前，作为理解这篇文章的基础，也许你需要先了解下一个嵌入式系统的大致组成。为此，你可以参考文章应用程序，操作系统，驱动程序和硬件。2.软硬不分家软硬不分家 我们做嵌入式开发的，应用永远记住一个公理，那就是在嵌入式系统中，软件硬件永远不分家(2)，这是不需要经过证明的。既然有这样的公理存在，那在实际嵌入式产品的开发过程中，我们可以想见将会有两班人马在一起努力。其中一班负责设计开发产品的硬件部分，另外一班负责设计在硬件上运行的软件部分。两班人马只有相

5、互协同好了，这个产品才能设计出来。实际上，在嵌入式系统产品开发领域中，硬件工程师和软件工程师恰是最最重要的两大类角色。前面所说的文章中指出软件是要依赖于硬件来工作的，那么我们下面具体讨论角色分工时，也应该自然的先讨论硬件工程师，再讨论软件工程师。但是，切记，在进入软硬件任一部分的开发之前，我们都要仔细的做好产品系统的需求分析和架构设计(3)。3.软硬件需求分析与系统架构师软硬件需求分析与系统架构师 一个嵌入式产品的最初起源不应该是起源于宇宙大爆炸，而应该是来自于出现在我们大 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,Ju

6、lianTec Atelier&http:/www.juliantec.info 4 脑中的某些概念。这些概念也许来自我们和朋友的聊天过程当中，也或许是我们看到了人家的产品受到启发而产生的。光从这些零碎的概念出发去开发产品是不行的。为了使概念中的产品在市面上具备竞争力，我们需要将其转换成真正的产品需求。一般来说，最初形成于脑袋中的概念只是需求的一个很小的部分。所以，我们需要从众多的渠道通过不同的方法尽可能的将需求收集完整。在嵌入式产品开发领域中，需求分析师角色会负责去收集这些需求，并将它们书面化，形成原始的需求文档(比方我们文章面向过程的分析(POA)，和面向对象的分析(OOA)中分析的CBM

7、项目)。至于收集的方法，则多种多样。或对待开发产品的最终用户进行调查走访，或对市面上同类产品的功能进行分析等等，我们这里不再详加讨论。原始需求收集完还不够，需求分析师角色还会对它们进行深入的挖掘与分析，最终形成书面的需求规范文档(Requirements Specification)。在需求规范中，通常描述了一系列的UseCase，也即最终用户在使用这个产品时的各种不同使用过程(可理解为用户与产品之间的交互过程)。在需求分析后期，另外一类角色，即软硬件系统架构师会参与进来。他们会和需求分析师紧密合作，从产品的整体角度出发，决定需求规范文档中哪些需求需要由硬件来完成、哪些需求又是由软件来完成。在

8、需求的软硬件界限大致确定下来后，软硬件系统架构师又会通力合作，设计好软硬件两个部分各自的内部架构。软硬件架构师必须具备深厚的专业技术积淀，所以他们经常由在软硬件领域摸爬滚打多年的资深工程师担任。除此外，他们也必须有很强的全局观，习惯于从整体的角度去把握整个嵌入式系统。具体来说，软硬件架构师必须习惯于殚精竭虑的考虑问题。同时应该具备良好的沟通能力，因为他们身处提出需求的客户和具体实现这些需求的团队之间，而时常要做类似下面这样的事情：?面对某一项需求，在经严格评估后认为毫无实现实际的可行性，或者实现它会大大影响全局设计的情况下。他们需要说服客户做出妥协，使之值之暂时接受一个没实现该需求功能的产品版

9、本；?假如某项需求是关键性需求。如果缺了它，该产品将毫无实际应用价值，或者毫无市场竞争力的话。他们又要殚精竭虑的思考出解决方案，并敦促软硬件开发团队努力实现之。硬件架构师在确定好需要由硬件来完成的需求后，会通过性价比分析来决定出能实现这些需求的最佳方案。在这个过程中，为了缩短产品上市的时间，也许他会尽量选用市面上的现有组件。他会根据自己的经验，将整个产品的硬件部分划分成若干个子系统，并理清它们之间的关系。这样做，一方面是为了能更方便的给下面的硬件工程师分配不同的任务，另外一方面，也是为了简化整个系统的设计。相比硬件架构师角色来说，软件架构师角色的工作可能更具艺术性。软件架构师通常会使用业界常用

10、的，诸如结构化的或者面向对象的建模方法来对软件部分的需求进行建模和整 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 5 体架构设计。相比于硬件架构设计，软件架构设计要灵活的多，隐藏其中的变化更加多样。软件架构师需要根据自己的专业经验、对各种利害因素加以权衡，从中选择出最有效的软件设计方案来。这不是一个容易的过程，相比于技术能力，它体现更多的是软件架构师整体思维的能力。在实际的研发过程中，为了使得研发更加有效率，软硬件架构师通常作为软硬件研发

11、团队的 Team Leader 来参与具体的研发工作。4.硬件开发工程师硬件开发工程师 在硬件架构师进行架构设计期间，其他硬件开发工程师可能也会参与进来，协助硬件架构师进行不同硬件设计方案的选择。在整体硬件设计方案架构完成之后，每一个硬件工程师可能会负责设计开发其中的单个子系统。这个过程主要是关键元器件的选型、以及相关电路的设计。电路的设计大都要求使用 Protl 等 EDA 软件来进行，在设计过程中会经常使用器件 datasheet 文档中的参考设计。设计完成后，各硬件子系统的电路设计完成后，会出来电路原理图，里面详细记录了硬件系统内各器件之间的连接关系。原理图对下面谈到的底层驱动开发工程师

12、来说同样重要。接下来，硬件开发工程师会根据原理图来进行 PCB 布线(所谓布线是指决定如何在印刷电路板上放置器件及它们之间的走线)。PCB 布线的好坏直接影响产品后续开发过程的执行顺利与否，所以必须严格按照布线标准来进行。布线结束时，硬件开发工程师需要准备好元器件清单(即 BOM 清单)，它详细记录了这个产品都需要用到哪些元器件，数量各是多少。此后，他们就会开始元器件的采购并联系厂家来生产 PCB 样板，以及完成特殊元器件的贴装(某些特殊的元器件没办法通过手工焊接到 PCB 样板上，需要请专门的贴片加工厂的机器来帮忙)。待PCB样板回来后，硬件工程师们会动手焊接调试之前设计的各个子系统。这个过

13、程的工作也许会全部由硬件工程师自己完成，但下文提到的底层驱动开发工程师通常也会参与进来一起进行联调。实际上，硬件各子系统的调试过程通常会延续至底层驱动软件开发结束为止。在调试过程，如果发现电路设计或者PCB布线上面的问题的话(4)，硬件工程师会详细记录下来，等到PCB的后续版本中去修改。硬件开发工程师除需要掌握模拟/数字电路设计等书本上能找到的基础知识外，还要求能熟练使用各种 EDA 设计软件以及电烙铁、万用表、示波器、逻辑分析仪等各种硬件设计工具。此外，在实际硬件的调试过程中，也时常需要写一些简单的软件程序，这就要求他们最好也掌握一些最简单的 C 及汇编程序设计的知识。还有一点值得一说，那就

14、是因为各种器件的技术资料通常都是英文的，所以硬件工程师们必须有很好的英文阅读能力。相比较于软件的开发来说，硬件系统的开发更加注重工程师的实践经验。久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 6 5.软件开发工程师软件开发工程师 对于一个嵌入式系统产品来说，虽然硬件系统是其存在于这个世界上的基础，但是更重要的还是软件部分。软件的稳定及出色与否，直接影响这个产品的市场接受度。就工作量来说，软件部分的工作量可能要更多于硬件部分。如文章应用程序，

15、操作系统，驱动程序和硬件中所阐述的那样，在嵌入式产品系统架构中，硬件通常只占一层，但是软件却可以分为好多层，各层之间通常维持一种单向的依赖关系。幸运的是，虽然工作总量可能会多点，但是软件部分的各层次通常可以以一种更加并行的方式来开发。这是因为软件各层之间的依赖接口(5)通常都会被设计成固定的、大家都认可的形式。只要接口固定下来了，各层软件的开发工程师就可以并行的、集中精力开发自己的那一层。这点不像硬件系统的开发那样，只能先设计好原理图，才能去制造PCB板；只能等PCB回来了，才能动手进行焊接和调试。对于嵌入式软件开发工程师而言，主要的工作就是用汇编/C/C+等语言设计编制程序，以满足软件部分的

16、需求。下面我们按照软件层次的划分来从低到高的分析参与开发的所有角色。5.1.系统软件开发工程师系统软件开发工程师 在文章应用程序，操作系统，驱动程序和硬件中，我们强调了系统程序软件是操作系统(包括镶嵌在其内部的驱动程序)。但实际上，我们认为，对于一个嵌入式系统产品来讲，你可以把除应用程序之外的其他所有软件都统称为系统软件。至于系统软件到底由哪几部分组成，很大程度上要取决于这个产品是否应用了操作系统、以及应用了何种操作系统。我们在下面分析参与系统软件开发的角色时，会以系统软件的各组成部分为基础(由什么部分组成，就会有什么角色的工程师参与开发)，从不使用任何操作系统、使用 uCOSII实时操作系统

17、、使用 Linux 操作系统等三种类型出发进行角色的分析，请注意用心体会。5.1.1.底层驱动开发工程师底层驱动开发工程师 系统软件开发中的最底层角色是那些底层驱动开发工程师。他们的主要任务是开发能用来驱动硬件正常工作的各种函数。这里的工作主要是读写那些记录在元器件datasheet中的各种寄存器(6)，以实现特定的硬件操作。除此外，他们还需要负责编写处理各种硬件中断的中断处理程序。久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 7 假如所开

18、发的嵌入式产品中不打算使用操作系统，那么这些函数被完成后，可能会以函数库的形式直接交给应用程序开发工程师去开发应用程序。假如产品中使用uCOSII作为操作系统，那么他们可能还会把实现硬件操作的这些函数封装成为一个个的任务(7)。假如产品中使用的是Linux操作系统，那通常他们会以动态可加载模块(module)的形式来开发设备驱动程序。实际研发中，无论是否使用操作系统，底层驱动程序开发工程师都要求有良好的软件编码设计能力(8)，同时还要求熟悉手头需要编程的硬件的工作原理。在某些情况下，甚至还要求能熟练使用示波器等工具，能看懂原理图及时序图等硬件开发工程师才具有的能力。5.1.2.应用软件运行平台

19、搭建工程师应用软件运行平台搭建工程师 我们认为，在一个嵌入式产品中，除了底层驱动程序外，其他所有的系统软件都是应用软件运行平台的一部分。这主要包括操作系统(OS)内核，以及若干中间件。我们这里所说的操作系统，重在强调它的多任务支持能力。现在市面上，不使用操作系统来支持多任务的嵌入式产品已经越来越少见了。至于中间件，我们可以认为是除了提供多任务支持的操作系统内核外的、其他任何支持应用软件得以运行的软件，如 GUI 系统、用于数据通信的协议栈、以及用于数据存储的文件系统或者数据库系统。这些支持性的软件本来可以归类到应用程序领域，但是为了更好的说明参与研发的角色，我们将他们归类为中间件。如果产品中用

20、的是 uCOSII，那上面的分割将很好理解。因为 uCOSII 实时操作系统本身非常简单，只提供了多任务的支持，所以要完成整个嵌入式产品所需要的其他支持软件就要单独另外再行选配。如果产品中使用的是 Linux，那也许，上面的分割将让你困惑。但是，你只要认为Linux是将某些中间件(如用于数据通信的TCP/IP协议栈)移到了Linux内核中去了就可以。下面，我们将根据上面的分割来分析对应的开发角色。5.1.2.1.OS内核调整移植工程师内核调整移植工程师 假如产品中不使用任何的操作系统，那整个应用软件就是系统里面唯一的一个任务，此时就不需要任何操作系统来提供多任务的调度和管理。唯一要做的，就是在

21、系统被上电时，确保得到执行的就是那个任务即可(9)。这种情况也许只适合于非常简单的嵌入式产品。随着软件系统需要完成的需求越来越多，在嵌入式系统产品中应用操作系统将变得越来越广泛。这个时候，就需要有一个专门的工程师角色来进行OS操作系统内核的调整和移植。要调整和移植操作系统内核到已焊接调试好的板子上，那调试移植人员不仅要非常熟悉 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 8 待移植操作系统的初始化过程和该操作系统中多任务的运行调度机制，还

22、要对板子上的处理器架构了然于胸。OS 调整移植工程师除了要确保所移植的 OS 在板子上能正常运行起来之外，还经常要负责对 OS 软件本身所提供的功能进行选择性调整，去除那些对当前产品来说多余的、不需要的功能。因为，对于一个嵌入式产品来说，其中的软件部分不仅要能完成既有的软件需求，还要特别注意自己的尺寸，尽量减小运行时对内存的需求量(即所谓的 footprint，软件功能多了，通常就意味着运行时需要更多的内存)。5.1.2.2.关键中间件开发工程师关键中间件开发工程师 在嵌入式系统开发领域中，单凭OS内核所提供的多任务机制，理论上我们就有希望开发出强大的产品来。但是你知道的，一个成功的嵌入式产品

23、的显示屏上总需要漂亮的操作界面、它总是可能与人家去使用网络进行通信、它总是需要在FLASH或者其他存储介质上存储数据。那么如果让应用软件开发工程师去从零开始打造这些东西，那他的任务就太过繁重。这反而会影响到应用软件开发工程师的本职工作：编写纯粹面向应用的程序代码，以实现特定的软件需求(10)。所以，最好有专门的工程师角色来将这些功能实现出来，然后交给应用软件工程师去使用即可。在一个嵌入式产品中，实现这些功能的软件即被称为中间件(11)。打个比方，在uCOSII中，这些中间件可能是lwIP协议栈和ucGUI系统；在Linux中，协议栈已经在内核中实现，但是GUI系统却通常需要另外的移植。OS 内

24、核和关键中间件等系统软件构成了应用程序软件运行的平台。在实际公司嵌入式产品的研发实践中，通常会很重视这种平台的建设。因为运行在上面的应用程序软件可以千变万化，但是应用软件的运行平台却是可以相对保持不变的。它通常可以连续的用在任何一款嵌入式产品中。5.2.应用软件开发工程师应用软件开发工程师 应用软件是嵌入式产品中软件部分的最上层。应用软件开发工程师需要对软件的需求有一个非常清楚的认识，在编码时也要严格遵循软件系统分析架构师的架构设计来。如果嵌入式系统产品中不使用操作系统，那应用软件开发工程师就直接使用底层驱动开发工程师所开发出来的函数库就行；但假如产品中使用了操作系统，那根据文章 应用程序，操

25、作系统，驱动程序和硬件 中的说明，编写应用程序所需要的通常只是那些由操作系统(如Linux)所抽象出来的，完整一致的应用程序编程接口(API)。当然，除此外，应用程序的编写通常都少不了要使用中间件本身所提供的函数接口，这点在使用uCOSII时尤其体现的明显。由于嵌入式系统产品本身就是面向特定应用行业领域的，所以应用软件开发工程师最好 久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 9 具备对应行业的行业知识。因为，除了开发程序所必须具备的通用

26、知识外，每个行业可能都会有它自己独特的行业知识的要求。比方，做 wifi 应用的，可能需要理解相关 IEEE 802.11x系列标准；做音视频监控的，可能需要理解各种音视频的编码标准，如声音 PCM 编码标准、MPEG 系列标准和 H.26x 系列标准等等；在当下的实际研发公司中，可能不会给需求分析师、系统架构师等这样的角色来专门分配职位。在这种情况下，我们的应用软件开发工程师在具体动手编码前，必须花一些时间应用文章面向过程的分析(POA)，和面向对象的分析(OOA)中提到的方法，尽自己的所能来分析需求，并完成系统的架构设计。6.软硬件测试工程师软硬件测试工程师 既然研发的是要推向市场给用户去

27、使用的产品，那就必须配备对应的软硬件测试工程师角色来对各阶段的产品进行测试。很难想象，一个没有经过严格测试的产品会得到市场的认可。一般来讲，在软硬件系统架构师分析需求、进行系统架构设计阶段的晚些时候，软硬件测试工程师就会开始按照需求规范文档及系统架构设计方案来写测试用例(12)。待软硬件产品都开发完毕并集成好后，他们就会从用户如何使用这个产品的角度出发，按照之前编写的测试用例文档，来一项一项的进行测试。需要说明的是，这里所说的测试重在对最终产品进行测试。它是黑盒性质的，就是将所要测试的东西看成是一个黑盒子，在不知道其内部如何运做的情况下，进行各项功能的测试。另外，在产品软硬件的研发过程中，也需

28、要进行测试。这种测试多数都是白盒测试，一般都由相应的软硬件开发工程师自己完成。比方应用软件开发工程师在开发一个软件功能模块的时候，必须自己写测试用例，用某些单元测试工具如 CUnit 或者 CuTest 之类的软件进行测试。7.选择定位好你自己的角色选择定位好你自己的角色 上面给大家粗略地介绍了嵌入式产品研发过程中，所涉及到的各种角色。你可以根据你自己的实际情况，如专业背景、性格、能力和兴趣等，来从中选择一个可以属于你自己的角色。需要注意的是，一般情况下面，你没办法马上将自己定位成软硬件系统架构师的角色，因为你还不满足相关的能力要求。更通常的，你需要更塌实一点，选择从软硬件开发工程师角色开始，

29、在学习相关技术知识的同时，慢慢地提高整体上的系统性整体思维能力，为充当更高级角色做准备。久联技术（JulianTec）您在 arm 架构下学习嵌入式 Linux 的上佳指导 Copyright 2010,JulianTec Atelier&http:/www.juliantec.info 10 注意 1.我们所关注的不是角色 A 在工作过程中如何同角色 B 去交互的问题(是通过电子邮件呢，还是直接走过去和他讨论呢)，我们更关心角色 A 会提供什么样的输出给角色 B 去使用。2.也许一个缺少了软件部分的嵌入式产品还能工作。那靠什么来驱动呢？绝对不会是靠二值逻辑的运行，也许是力学的各种原理，谁知道

30、呢。但那只能算是一种“机械装置”，而不是嵌入式系统。3.我这样说，感觉上好象是要严格的做完所有需求分析和架构设计才能进入实际的软硬件开发。但实际上，我们在做开发的时候，应该摈弃那种严格意义上的瀑布流模型，而应该使用增量迭代模型。这是系统开发的两种开发模型。前者主张一个系统的开发应该严格的划分成若干阶段，在进入后面的阶段前，必须先正确的全部完成掉前面阶段中所要做的所有任务。而后者，则主张整个开发周期可以分成若干次迭代，每次迭代过程都包含前面瀑布模型中所规定的所有阶段。这样，当若干次迭代中每一次迭代完成的时候，所要设计的系统都会出来一个版本。前面版本相对来说不那么完善，后面的版本则会越来越完善，这

31、就是增量概念的体现。4.实际上，这是常有的事情。任何人都会出错，硬件工程师也不例外。其实，在这个过程发现错误还是比较幸运的，要等到产品都已经在工厂批量化生产了，才发现 PCB 设计及布线上面存在问题的话，那通常会造成极大的经济损失。所以，这不像软件世界，产品出去了还可以发布新的补丁程序，或者叫客户去升级产品中的 firmware。5.这些接口，其实都是一些函数(函数中实现了各种很小的软件功能)的集合。在软件部分的各层之间，通常是下面层次的软件来实现这些函数，然后将其交给更高层次的软件去使用。6.不同于CPU架构编程模型中定义的各种寄存器(PC,SP,PSW,通用寄存器等)，这些寄存器属于I/O

32、地址空间，也时常被称为I/O端口。详细请参考文章计算机硬件系统架构概述中的论述。7.在使用 uCOSII 的产品中，应用程序软件通常也被实现成多个不同的任务。它们如果需要完成特定的硬件操作，则一般要和那些专用于完成硬件操作的任务进行通信，委托它们来帮忙完成特定的硬件操作。8.使用操作系统的话，还要求熟悉操作系统提供的、可以为驱动程序所使用的各种接口。这一点对 Linux、winCE 等操作系统来说尤其重要。9.实际上，在唯一的应用任务得到运行之前，一般都会有一小段程序负责系统内关键硬件器件的初始化(如 cpu、内存控制器等)。初始化完成后，控制流程才跳转到那个唯一的应用任务所实现的 main

33、函数中去继续执行。在实际的研发中，这一小段初始化程序一般由底层驱动开发工程师开发好。应用软件开发工程师只需要负责完成从 main 函数开始的应用逻辑。10.为什么这么说？对于应用软件开发人员来讲，他需要关注的是在屏幕上显示一些什么内容，而不是在按下屏幕上某一个按钮后，GUI 系统内部如何工作来 show 出这些内容；是通过网络要向网络另外一端传一些什么数据以及这些数据是以什么样的格式进行传输，而不是如何在网络连接介质上进行传送；所以，他们最好集中时间和注意力干他们自己的事情。11.之所以会被称为中间件，是因为这些软通常介于应用程序软件与更底层软件的中间。这更底层软件要么是操作系统内核这一层，要么直接是底层驱动程序这一层。12.在软件需求规范文档中详细描述了用户使用产品的 UseCase。那测试工程师就会从这些 UseCase 中抽出一系列的测试用例。测试用例中规定了用户在做过何种操作后，产品应该给出何种正确的响应。在测试过程中，假如实际得到的结果和测试用例中规定的预期结果相一致，那本测试用例即告通过。