Question

有人在DO-178航空电子设备环境中成功使用了Rhapsody吗？也就是说，与FAA/DER流程合作，向他们提供工件并获得批准。由于我的理解是Rhapsody不是一个可认证的MDD工具，我很好奇是否还有其他缓解因素。

如果你成功了，你采取了哪些步骤来实现这一目标？

感谢您的任何反馈和见解。

Answer 1

我在一个按照DO-178B D级开发（但未经认证）的项目中使用了Rhapsody。需求在DOORS中管理，并使用RhapsodyGateway工具链接到Rhapsodys中，该工具运行良好。这很重要，因为可追溯性是178B的关键部分。

该软件在Rhapsody中建模，然后手动生成代码。选择手动代码生成，因为自动生成代码需要Rhapsody作为符合178B的开发工具。我不知道IBM是否为Rhapsody提供178B认证。

使用定制的测试工具对软件进行需求验证，为此，我们必须对该工具进行一些重要的测试，以使其成为验证工具。

你的问题很难回答，因为你没有包括任何关于你正在工作的178B级别的信息，你正在使用/计划使用的工具（Rhapsody除外），或者你是否打算自动生成代码等。

希望这能有所帮助。

Answer 2

我有使用Rhapsody C++进行DO-178B A/B级兼容项目的经验。

根据覆盖率要求（包括MC/DC覆盖率）验证自动生成的代码是否达到适当级别。由于生成的代码经过严格的静态/动态测试和手动审查的充分验证，就像它们是手工编码的一样，Rhapsody工具的资格认证不是强制性的。

我们在定制Rhapsody代码生成属性方面付出了很多努力，以仅生成所需的代码，如ctor/dtors和get/setters，并避免使用不确定的库函数或具有动态内存分配的库函数。

我们能够充分利用往返工程，使Rhapsody模型文件而不是代码受到版本控制，因为模型包含所有代码。

Rhapsody UML应该被考虑用于开发可重用和可移植的软件架构。

Answer 3

Rhapsody正在我们的A/C/D级项目中与Arinc 653一起使用。由于正在验证Rhapsody（自动代码生成器）的输出。

因此，限定Rhapsody是不必要的Rhapsody在可追溯性和生成或修改测试脚本方面具有优势，只需更新“标签”字段即可。

因此，不需要修改整个测试脚本或测试脚本中的跟踪。