MachineWare为嵌入式程序员提供开发、集成、测试和调试代码的硅前开发平台。
虚拟原型的内容，我们的公众号累积有超过了百万字。为什么我们投入这么大精力？因为我们知道，启动虚拟原型项目之前，用户要能够对虚拟原型进行完整评估和理解，才能发挥其价值。要完整理解虚拟原型，需要时间。虚拟原型，会让整个行业和生态受惠；而虚拟原型的普及和传播，早晚需要人去做。虚拟原型在国内，是一个相对前沿又非常技术底层的概念。很多人初次听到虚拟原型，容易和 Hypervisor 混淆，我们也经常在客户现场看到。知识的普及，一直是任重道远，希望这篇文章可以帮你了解更多。
当前的嵌入式软件开发人员，肩并肩挤在寒冷的调试实验室中，在最终系统的物理原型上集成和测试代码。除了不便之外，这种方法还有两大问题。在一个庞大的软件团队中复制原型的成本相当可观，而且这些系统必须得到维护和管理。为了最大限度地提高硬件利用率，程序员轮班工作已成为一种普遍现象，这又增加了不便。改用高度联网的系统意味着程序员可以在办公室而不是实验室工作，但这并没有降低相关成本。
MachineWare 提供了ARM 架构的硬件等价环境，部署到AWS、Baidu 或者私有云中。
避免这些问题的唯一方法是为嵌入式程序员提供一个硅前平台，用于开发、集成、测试和调试他们的代码。虚拟原型（SoC 和硬件系统的抽象软件仿真模型）正是这样一种解决方案。它们包含嵌入式处理器的快速指令集模拟器（ISS），能够执行与生产系统相同的代码。虚拟原型可以与虚拟和现实世界的 I/O 设备进行交互，这是系统测试的重要组成部分。虚拟原型还能更好地测试异常情况，包括注入可能导致实际硬件损坏的虚拟故障。虚拟原型可在整个嵌入式软件团队中部署，而无需支付构建和维护物理原型的成本。
最重要的是，虚拟原型缩小了 TTM。由于虚拟原型不需要包含许多实现细节，因此可以与 SoC 的寄存器传输级 (RTL) 硬件设计并行开发和使用。这就实现了真正的软硬件协同开发，并使项目进度大幅 "左移"。设计与嵌入式代码之间的不一致性会被及早发现，从而大大降低了因功能问题导致芯片转向的几率。
在硬件虚拟原型出现的同时，软件开发也经历了自身的演变。如今，许多编程项目都使用持续集成（CI），即经常（有时一天数次）向主资源库检查代码更改，并立即重建和测试软件可执行文件。CI 方法与只在指定检查点合并所有程序员代码的传统做法形成鲜明对比。到那时，代码的各个部分可能已经有了很大的差异，导致集成步骤充满挑战，并需要大量的调试工作来解决问题。CI 可以立即发现这些问题，从而快速、轻松地解决它们。CI 有时还与持续部署（CD）相结合，在 CD 中，通过所有自动测试的成功构建将在所有系统上发布到生产中。
MachineWare 和生态伙伴可以帮助用户搭建完整的虚拟整车开发环境。
松下汽车采用虚拟原型：在 AWS 上部署虚拟 ECU
MachineWare 对汽车软件开发生态提供了完整的支持。
VPK 可集成到先进的 CI/CD 流程中，为嵌入式软件开发和测试创建高效的管道。容器是一种 "一次构建，随处运行 "的可执行软件包，其中包含在多种计算环境中快速可靠运行所需的一切内容。此外，检查点/恢复功能可避免冗余工作，从而大大加快测试周期。VPK 通过广泛的分析和调试功能提供额外的价值，并与各种先进的软件开发和测试技术无缝集成，包括：
-
GitLab 或 Jenkins DevOps 平台
-
-
-
用于管理 Kubernetes 集群的 Rancher 软件栈
原文始发于微信公众号（虚拟原型 Virtual Prototyping）：利用虚拟原型，实现整车开发 CI/ CD 流程
