并行工程/简介

使命宣言

本维基教科书的宗旨是创建一个活生生的文件，描述什么是并行工程以及它如何有用。它面向工作场所的入门级工程师。

定义 并行工程是一个过程，在这个过程中，适当的学科被委派以交互方式工作，以构思、批准、开发和实施满足预定目标的产品计划。如 http://www.mne.psu.edu/lamancusa/html/ConcEng.htm 所定义

为什么要使用维基教科书？

维基协作是一个非常新颖的事物，教师和学生都鲜少为新的维基环境做好准备。但是，我要说，它带来的益处非常大：参见诸如人体生理学（已迁移到其自己的专用维基网站）和教育基础与教学评估（已出版第四版）之类的书籍，这些书籍是我们最成功的案例。学生不仅可以通过编写自己的段落来学习，还可以通过审查和建设性地批评他人的段落来学习。被要求改写或澄清某件事可能会迫使学生在自己的脑海中重新构建和强化这些想法。所以，即使情况很艰难，也要相信结果会非常有意义！（维基用户 Whiteknight 的评论）

产品概念

ME 518 并行产品设计课程中的学生进行了一次头脑风暴，以确定他们希望在关于并行设计的“书”中看到什么。

产品数据表

关于并行工程维基教科书应该做什么的说明

并行工程

• 作者：Michael Koch，来自 ME519 论文...请审查和编辑！由于我从另一篇论文中摘录了它，因此可能存在问题

并行工程方法仍然是一种相对较新的设计管理系统，但在近年来已经成熟，成为一种优化工程设计周期的定义明确的系统方法。^[1] 正因为如此，并行工程引起了工业界的广泛关注，并在众多公司、组织和大学中得到实施，最著名的是航空航天工业。^[2]

并行工程的基本前提围绕着两个概念。第一个概念是，产品的整个生命周期，从功能、可生产性、装配、可测试性、维护问题、环境影响，最后到处置和回收，都应该在设计初期阶段仔细考虑。^[3] 第二个概念是，上述设计活动应该同时发生，或者并行进行。总的目标是，这些过程的并行性质显著提高了生产力和产品质量，这些方面显然是当今快节奏市场中的重要因素。^[4] 这种理念是并行工程成功关键，因为它允许在设计过程的早期发现错误和重新设计，此时项目仍然处于更抽象的、可能还是数字化的领域。通过尽早定位和修复这些问题，设计团队可以避免在项目转向更复杂的计算模型，最终进入物理领域时，经常出现的昂贵错误。^[5]

如上所述，设计过程的一部分是确保整个产品生命周期都被考虑在内。这包括建立用户需求，传播早期概念设计，运行计算模型，创建物理原型，最终制造产品。该过程还包括充分考虑资金、人力资源能力和时间，这些方面通常不会被直观地考虑，但它们是并行工程系统成功的极其重要的因素。与之前一样，广泛的预先规划允许在实际物理生产开始之前尽早发现不可预见的设计问题，以便在实际物理生产开始之前修改基本概念设计。通过正确地做到这一点，可以节省大量的资金，这通常是公司转向并行设计框架的决定性因素。^[6]

并行工程取得巨大成功的最重要的原因之一是，从定义上来说，它重新定义了数十年来普遍存在的基本设计过程结构。这种结构基于一个顺序设计流程，有时被称为“瀑布模型”。^[7][8] 并行工程显著修改了这种过时的方法，而是选择使用被称为迭代或集成开发方法的方法。^[9] 两种方法之间的区别在于，“瀑布”方法以完全线性的方式进行，从用户需求开始，依次向前推进到设计、实施和额外的步骤，直到你得到一个完成的产品。这里的问题是，设计系统不会从它所处的步骤向后或向前查看以解决可能存在的问题。如果出现错误，设计通常必须废弃或大幅修改。另一方面，迭代设计过程更具循环性，正如前面提到的，它考虑了产品的整个生命周期，从而允许采用更具进化性的设计方法。^[10] 两种设计过程之间的区别可以在图 1 中直观地看到。

图 1 – “瀑布”或顺序开发方法与迭代开发方法

这种新方法的一个重要部分是，由于并行工程的协作性质，单个工程师在整个设计过程中获得了更多的话语权。虽然这在很多人看来可能无关紧要或无关紧要，但赋予设计师所有权在员工的生产力和产品的质量中起着至关重要的作用。这源于一个有时不为人知的现实，即一个对自己的工作有满足感和所有权的个体将会比一个被分配了任务但对总体过程没有发言权的员工更加努力地工作，并设计出更加强大的产品。^[11]

通过实施这种彻底的变革，许多组织和管理方面的挑战将会出现，在公司和组织向这种体系转变时，必须特别注意这些挑战。从这个角度来看，诸如早期设计评审的实施、工程师之间沟通的实现、软件兼容性以及开放设计流程以允许并发等问题都会带来自身的问题。 同样，必须有强大的团队合作基础，因为该方法的总体成功取决于工程师有效协作的能力。这通常是一个难以克服的障碍，但必须尽早解决，以避免以后出现问题。

同样，现在比以往任何时候都更重要的是，软件在工程设计过程中发挥着巨大作用。无论是从 CAD 软件包到有限元分析工具，快速轻松地修改数字模型以预测未来设计问题的能力对于您使用的任何设计流程都非常重要。但是，在并行工程中，软件的作用变得更加重要，因为协作的本质必须考虑到每个工程师的设计模型必须能够相互“沟通”，才能成功地利用并行工程的概念。当我们研究美国宇航局喷气推进实验室的 Team-X 设计方法以及分布式并行工程时，我们将更深入地探讨这一点，它们都严重依赖于复杂的软件系统集成，将并行工程提升到一个新的水平。

极度协作

• 由迈克尔·科赫输入，将会回来清理……另外，不确定这是否适合这个地方？
• 我认为这可能更适合“通信系统”部分，通信团队的任何成员同意吗？

极度协作，这是格洛丽亚·马克创造的一个术语，用于描述美国宇航局喷气推进实验室 Team-X 对并行工程的应用方法。Team-X，也称为高级项目设计团队，成立于 90 年代中期，作为美国宇航局内部咨询小组，以及外部实体在新的太空任务提案设计方面的咨询小组。其总体目标是减少完成这些定义任务所有方面的提案所需的时间。下面我们将看看极度协作是如何运作的、它为什么取得成功以及存在哪些局限性 [20]。值得注意的是，由于该方法已证明可以将生产力提高一倍 [25]，因此许多组织纷纷效仿。

简而言之，Team-X 方法几乎与并行工程相同，但他们将该概念进一步发展，基本上将所有设计工程师集中在一个大型房间中，进行密集的并行设计会议。在这个被称为项目设计中心的房间里，设计团队利用联网计算机访问数据存储库、实时设计信息以及计算机建模和模拟工具来创建最终设计 [24]。这些设计会议通常持续大约 3 到 4 个小时，来自机械、结构或电气等各个学科的 10 到 20 名工程师以及一名协调员和客户共同努力快速有效地创建设计提案 [23]。

图 2. Team-X 设计会议正在进行中

对这种协作进行预先规划极其重要，以确保一切到位，以便工程师能够快速工作并避免设计过程中的停滞。这些停滞，或称为“延迟”，最终必须不惜一切代价减少。延迟的减少本质上是 XC 取得成功的关键。在传统的协作方法中，工程师可能要等待数天或数周才能获得重要的设计信息，从而导致项目延误。在 XC 中，通过将所有相关的工程师集中在一个地方，延迟被大大减少，从而能够通过本地协作快速找到并解决问题。我认为这非常有趣，因为 XC 专注于减少设计中最明显的时效问题 [22]。关于未来的研究，这种类型的协作似乎可以在分布式方式下模拟（即，工程师不在本地，而是仅通过互联网连接）。

XC 的另一个重要部分是组织结构。XC 的设计理念是平等主义。XC 正常运作需要最少的管理干预。这已在研究中得到证实，研究表明工程师将 10% 的时间浪费在等待管理层批准上，并且工程师咨询“知识网络”而不是其主管的效率得到了证实。尤其是，平等主义结构在工程设计中的成功证明对于赋权工程师、赋予个人所有权非常重要。在许多领域，这一点已经得到体现，例如社区组织，但今天许多工程组织似乎缺失这一点。证明“扁平化等级制”是组建工程设计团队的一种可行方式，这似乎可以通过使用分布式协作工程 [22] 来进行更广泛的应用，这将是本文后面讨论的主题。

最后，使 Team-X 的并行工程方法如此成功的是它利用了社会和电子网络。通过将整个设计团队集中在一起，极度协作成功地使高效的人力网络得以发展，消除了电子邮件、电话和管理层审批等障碍，这些障碍往往会阻碍复杂系统的设计。关于一个设计领域的相关对话可能会被一位工程师无意中听到，该工程师发现这些信息有用，因此，关于设计信息的对话更加开放。此外，由连接的电子表格实现的电子网络使工程师能够快速共享他们计算出的可能与其他设计师工作相关的數據。总体效果与延迟的减少相关，而延迟是复杂系统设计中的一个主要问题 [21]。

然而，马克指出了一些局限性，这些局限性使该方法无法在所有情况下实施。重要的是，设计团队必须能够灵活地适应在社会封闭的环境中大型设计团队工作所需。如果团队成员固执或碰巧与同事相处不融洽，这可能是一个主要问题。团队成员还必须对自己的错误被公开广播到整个团队持开放态度，因为当发现或质疑错误或判断失误时，就会发生这种情况。最后，由于一个房间里可能有多达 20 人，每位工程师必须能够在嘈杂拥挤的房间里工作。通常，可以通过仔细选择团队轻松克服这些局限性。然而，这些仍然是必须考虑的现实问题 [21]。

总的来说，Team-X 使用的极度协作方法已被一次又一次地证明是非常成功的，当设计工程师能够集中在一个房间里时。这些设计已被证明具有很高的质量，并且能够快速有效地完成 [21]。但是，当所有相关方都不在一个地方时会发生什么？在下一部分中，我们将研究当前用于连接可能分布在世界各地的设计工程师的方法。这个主题非常重要，因为越来越多的公司意识到，最具专业知识的人可能不在自己的公司，这是推动向更分布式设计框架转变的一个关键动机 [4]。

分布式并行工程

分布式并行工程是一种快速流行的准新设计方法。简而言之，分布式并行工程基于与本地并行工程相同的基本概念，但更进一步，利用无处不在的宽带互联网连接工程师、经理和用户，他们可能分散在世界各地，共同创建独特的產品 [12]。如前所述，推动这一趋势的主要原因之一是，随着产品和系统的复杂性不断提高，专业知识往往不再局限于本地环境 [4]。出于这个原因，分布式设计已成为任何设计团队在创建强大功能性產品时必须考虑的一个重要方面 [26]。

由于并行工程的基本概念通常为人所知，分布式并行工程 (DCE) 面临的主要障碍是软件层。目前，有大量软件包，无论是 CAD、CAM、FEA 还是其他软件，它们都实现了巨大的生产力飞跃，以及对產品功能的深刻洞察，而这些洞察在最近之前是不存在的。但是，这些软件程序的通信能力一直是真正成功分布式设计的主要障碍之一 [12]。

许多实体都尝试设计这种分布式协作系统。Mohamed 提出了一种基于 Web 的系统，允许开发人员共享数据、进行沟通、修改几何形状，以及确保整个项目的一致性。“STEP”是一个 ISO 标准，用于分布式工程信息传输 [27]，这是该系统的一个关键特性。Quan 和 Jianmin 提出了另一种基于 Web 的方法，该方法利用四个不同的模块来实现产品设计：协同设计、可视化、制造分析和服务模块。作者还认识到知识处理技术对于捕获重要的设计信息以供日后使用的重要性 [12]。Nahm 和 Ishikawa 开发了另一个称为 ANetCoDE 的基于互联网的设计环境。这个网络设计系统是为了了解产品分解及其增强分布式设计方法的能力而创建的。据作者介绍，该方法非常成功 [28]，经过检验，它似乎与 ModelCenter 具有许多相似之处，ModelCenter 是一款专有程序，旨在促进项目协作 [29]。最后，一个主要基于 Web 的软件包 VOICED 应运而生，其目标是捕获设计知识并利用它来帮助未来的概念设计 [6]。随着工程设计变得越来越复杂，知识捕获的概念在概念设计阶段变得越来越重要，它使设计师能够借鉴过去的知识，避免“重复造轮子”，以及在设计和生产过程的后期避免代价高昂的错误 [30]。

所有上述设计系统之间存在的共同点是，基本框架都位于基于 Web 的领域。这对分布式并行工程的想法很重要，因为共享信息的机制必须能够从世界任何地方访问。这使那些参与项目的人能够快速轻松地从任何地方、任何时间访问信息，并立即更新相关信息。

然而，这并不意味着所有工具都必须是基于 Web 的。目前，很难想象有一个功能齐全的有限元分析软件包可以在虚拟环境中运行。浏览器中必须运行的资源数量可能会导致软件崩溃。当然，只要本地软件能够与基于 Web 的协作设计程序交互，这并不重要。这使真正的分布式协作设计环境成为可能，信息可以轻松快速地共享。上述许多分布式并行工程框架都设计了缓解这些问题的方法 [6, 12, 27-30]。

这种日益分布式的协作模式契合了谢列梅托夫提出的“层次”框架，他是墨西哥石油研究所的研究员。他的工作主要集中在石油行业，但也对工程设计具有广泛的应用。这些层次按以下顺序排列，旨在说明在将工程流程向更分布式的协作模式转变过程中发生的自然演变过程。

第一级目标是确保工程软件能够与公司或组织级别的其他应用程序互操作[30]。互操作性取决于“开放标准”，即一套规范软件包之间相互“通信”方式的规则。近年来，杰夫·卡普兰在政府领域大力推动了这一理念，而在工程领域也同样重要[31]。穆罕默德在他的协作框架中使用 STEP（ISO 10303） [27] 就是开放标准在实践中的一个很好的例子。

第二级旨在确保软件包能够通过将数据存储在服务器端并在需要时调用数据，整合来自不同位置生成的数据。这有效地减少了错误，并允许更轻松地扩展，同时通过将数据存储在异地来提高数据完整性。

第三级更进一步，允许通过一个主门户访问应用程序，从而使设计流程更加流畅，并在虚拟意义上实现更大的集中化。

最后，第四、第五和第六级更具雄心。它们分别旨在创建虚拟应用程序、用户生成的虚拟应用程序，以及最终自动生成的应用程序。从直觉上讲，这些似乎要困难得多，但它们将带来的机遇可能非常重大，因为它将迅速分散设计流程，并允许更大的灵活性[30]。

上述层次体系很好地说明了软件必须经历的演变过程，以便能够实现一个健壮的、分布式的协作工程环境。然而，上述层次需要与通常是专有且封闭的系统一起工作，因此难以更改和修改。这是在先前几节中提到的方法和软件基础设施中经常出现的一个重大问题。在大多数情况下，这些方法主要存在于公司或大学等机构中，这些机构在组织结构和必须遵循的协议方面具有不同程度的正式性。然而，这种设计、组织和生产方式正在缓慢发生变化，许多人认为这种变化是革命性的。在下一节中，我们将展望软件工程领域，在该领域中，“开放”协作的理念已变得极其流行，并催生了诸如 Linux 操作系统、Apache Web 服务器和维基百科等软件。

开源软件开发

• 来自 Michael Koch 的内容将很快整理……另外，我不确定这是否适合放在这里？

在过去的几十年里，开源设计方法，或简称为开源，已经从一个有点模糊的概念发展成为许多人认为正在迅速取代已存在数十年的过时的封闭系统的范式转变。正如埃里克·雷蒙德所说，“开源的运作和决策模式允许不同议程、方法和优先事项的并发输入，这与更封闭、更集中的开发模式不同。”[32] 这种设计模式与本文中提到的更成熟的制度化方法形成对比。

那么什么是这种“开源设计方法”呢？本质上，开源是一种相对非结构化的软件包或产品开发方式。简而言之，开源软件开发是指将源代码通过互联网公开，并鼓励对其进行修改、使用和分发，作为产品成功的关键[35]。

与并行工程类似，设计和实施由可能在地理上分散的个人以高度并行的方式进行。然而，与前面提到的方法存在着显著的差异。具体来说，参与者没有直接的货币报酬[33]。贡献者可以随时加入或离开，并且不会因这种行为而受到任何影响[1]。源代码，即软件的内部运作机制，将与最终的软件产品一起公开分发[33]，其他开发者可以从该代码中开始独立的项目，也称为“分支”。分支是一种比较罕见的现象，但在 Linux 和维基软件等更流行的程序中已经发生过好几次[1]。开放性使这些项目周围能够形成更广泛的对话，这也是开源成功的关键之一。

另一种可视化设计过程的方法是使用大教堂与集市类比。埃里克·雷蒙德提出的这种模型被广泛用于描述开源设计的工作原理。大教堂代表公司，一个高度组织化、封闭和等级化的机构，其任务是生产软件或飞机等产品。用现代术语来说，大教堂可以比作微软或波音等公司。另一方面，集市代表一个相对扁平化和开放的组织结构，其中贡献者具有平等的发言权和代表权[32]。集市作为熙熙攘攘的区域的形象，人们在那里展示自己的想法和议程，很好地说明了开源的工作方式[33]。这些描述暗示了每个系统成功和失败的原因。

开源的精妙之处在于，像 Linux 操作系统这样的大型复杂项目可以被分解成更小的任务，由一大群志愿者来完成。通过利用这个庞大的团队，所利用的脑力在公司环境中是无与伦比的。当然，必须有一个明确定义的审查流程，以确保提交的是高质量的工作，并避免代码“分支”的可能性[36]。

同样地，庞大的志愿者团队允许应用 Linus 的定律，该定律指出：“如果给足够多的眼睛看，所有的缺陷都是浅显的。”[32] 这意味着，通过利用这个贡献者网络，可以找到和修复源代码或设计中的任何问题。在软件开发领域，调试可能是一项繁琐的工作，尤其是在处理数百万行代码时。通过创建不对称的分布式网络，由于工作的并行性，这项任务会显著减少[33]。同样的理念可以应用于维基百科，信息在世界各地的用户之间进行审查和辩论，从而创建了一个强大的信息数据库，在现今可能无与伦比。

同样地，查尔斯·利德比特指出，以往的组织模型严重依赖于专家必须汇集到机构中才能创造产品或创新的理念。示例机构包括微软、斯坦福大学或喷气推进实验室。开源的理念颠覆了这一理念，它不依赖于机构，而是依赖于一个由开发者和贡献者组成的社区，他们受实用性、自豪感和乐趣等因素的驱动来创造创新。对许多人来说，这可能看起来令人费解，但在回顾人们如何围绕社区需求或问题进行组织的历史时，就非常有道理了[2]。

总之，开源软件开发是一种与前面提到的更成熟的设计方法截然不同的方法。开源软件开发的核心是一个平等主义的设计过程，旨在赋予每个人对其工作内容和解决设计问题的方