ESE模块15 项目I

金属探测器项目，我们大多数人可能都熟悉机场安检时使用的金属探测器。 然而检测金属方法是许多应用技术领域需要解决的重要任务。

在这个小项目中，本教程中选定的元素将在一个应用程序中协同工作。 具体的（物理）任务（金属检测）应该通过数字信号处理的方式来解决。 如果将所实现的解决方案小型化，就会出现一种智能传感器。 我们实验硬件的右侧是一个用于比较的工业电感式接近传感器。

将开发具有微控制器控制的金属探测器。 要使用的硬件是 mySTM32 Board light 和 myFinder 金属探测器附件。

为给定任务开发解决方案需要对所用金属探测器上的物理过程有一定的基本了解。

myFinder 金属探测器附件是脉冲感应金属探测器。 脉冲感应过程的特点是结构简单而坚固，具有故障安全功能和高性能（搜索深度）。

脉冲感应金属探测器由以下部件组成。

1. 电源
2. 脉冲发生器
3. 输出级
4. 搜索线圈
5. 放大器级
6. 评估逻辑
7. 用户界面（HMI、用户输入和输出）

系统的一部分应设计为带有微控制器的数字解决方案。

脉冲感应工作原理

PI金属探测器的基本原理是基于电磁感应。 为此发出强烈的电磁脉冲。 这会在脉冲范围内的金属物体中感应出涡流。 金属物体中的涡流又会产生电磁场，这些电磁场可以作为脉冲的“回声”被接收和评估。

线圈用于发送电磁脉冲。 然而，该线圈也可用于接收回波信号。 接收到的回波必须显着放大，以便我们对其进行评估。 下图显示了 PI 金属检测机的典型信号曲线。

黄色信号显示传输的脉冲。我们称之为线圈的初级信号。红色信号是输出信号经过线圈放大后的结果。我们必须从这个信号中读取所谓的二次信号（回声）。可以看出，脉冲之间有更长的停顿。这用于为功率级的电容器充电。电磁脉冲的高功率要求不应直接来自主能源，而是来自适当尺寸的缓冲电容器。当然，它需要时间来充电。对于这个电路，大约需要 1 毫秒。那是脉冲之间的长时间停顿。这里使用的搜索线圈需要大约 70 到 100 微秒才能在其周围完全建立电磁场。这是主信号（脉冲）的最佳持续时间。脉冲越短，磁场能量越小，搜索功率越低。如果脉冲更长，电流将不再流入电场的建立，而是无用地转化为热量。以下图像和视频显示了金属接近线圈时的信号流。

可以清楚地看到当金属物体靠近时次级信号是如何变化的。 在脉冲结束后，回波显然不能特别好地评估。 但是在脉冲后大约 10 到 20 微秒，可以清楚地看到可以轻松评估的信号曲线。

PI金属探测器的功能原理可以总结如下：

1. 1 到 2 毫秒充电（充电）
2. 70 到 100 微秒发送脉冲（pulse脉冲）
3. 至少 10 到 20 微秒等待时间消隐辅助信号（采样延迟）
4. 模拟信号的采集和评估（样本）
5. 记录信号的评估（处理）
6. 显示结果 (显示)
7. 继续 1. 所以重复这个过程（重复）

以下组件用于此处描述的项目。

• mySTM32 Board light 用于输入和输出、控制和评估以及通过 USB 供电
• Metalldetektor Add-On myFinder 对于所需的附加组件：输出级、搜索线圈和放大器级
• Kabelsatz 进行必要的连接

当然也可以为项目设计和制造您自己的电路。 这里提到的一些参数可以改变。 基本原理保持不变。 示波器可能是设备的有用补充，但并非绝对必要。

该项目可分为以下工作包：

1. 任务分析和功能原理
2. 起草解决方案概念
3. 解决方案的实现
4. 测试和
5. 解决方案的文档
6. 移交

具体的工作组织和（如果适用）任务的分配取决于各自的背景，当然可能会有所不同。

一个待开发的系统的需求大致可以分为以下几类：

• 一般要求、顶级要求
• 功能需求，通常是主要需求（功能需求）的规范
• 非功能性需求，通常是质量需求（非功能性需求）
• 其他要求，例如对项目组织的要求（例如过程要求）

现代需求定义是从用户的角度进行的。 UML 和 SysML 为此提供了一种特殊的表示形式：用例图。 在用例图中，系统应该为 WHO WHAT 被制定出来。 下图以用例图的形式显示了金属检测机的用户视角。

创建用例图的基础知识非常容易学习。

对于功能需求，即 HOW ，系统应该提供所需的性能，例如，UML 活动图作为一种可能的表示形式。

使用预期流程对用例进行细化称为场景或用户故事。 下图显示了上述系统用例的可能场景。

创建活动图并非易事，但建模简单的流程图很容易学习。

综上所述，可以说使用 UML 和 SysML 的建模选项可以精确地得出以下关于要开发的系统的陈述：

• WHAT 系统应该做什么 = 用例 UseCase
• WHO 谁应该使用该系统 = 角色 Actor
• How 系统应该如何使用 = 场景 Szenen

即使本课程中描述的过程是模型驱动的，在实践中仍然存在提交项目相关文件的任务。员工在文字处理系统或基于数据库的管理工具中手动输入的文档和需求规范在或多或少的短时间内往往会偏离系统的实际情况。

在编程领域，这个远离系统现实的编程接口（API）的文档化问题，早已得到逐步解决。系统现实，即当前的源代码和文档，不再是单独的工件，而是一个。从源代码中自动生成文本文档或帮助系统形式的所需解释。但是，要做到这一点，必须在代码中输入特殊语句作为注释。这些特殊语句最终是一个生成器脚本，它指示文档生成器文档的外观。

此处应遵循相同的方法，即系统的文档最终只是从系统现实中自动生成的输出，或者更确切地说是从系统源中生成的输出。系统源是模型。所需的文档应从模型自动生成。为此，我们使用 SiSy 中的文档生成器。

从模型生成的文档基于经典创建的文本文档，但有一些细节。为了深化这些方面，以下是有关本课程中提供的文档范围的深入信息。

• 使用文档生成器的注意事项
• 基于模型的系统需求规范的大纲提案, SRS
• 基于模型的测试用例的大纲提案, TC
• 基于模型的技术系统文档的大纲提案, TSD
• 基于模型的用户手册的大纲提案 , UM

在这个项目中，我们将应用课程中学到的建模技术。 我们使用 SysML 用例和活动图、UML 类图和 STM32 的类库。 为此请创建一个新的 SiSy 项目。 执行以下工作步骤：

1. 启动 SiSy
2. 创建一个新的 SiSy 项目并选择项目配置文件过程模型文件夹
3. 从 LibStore 加载带有“Referenzmodell Embedded Systems Engineering” (“参考模型嵌入式系统工程”)的项目模板

执行以下工作步骤：

1. 完成用例图
2. 用用户场景完成活动图
3. 生成系统需求规范 SRS 文档

让我们再次使用 SRS 可视化任务。 这包括使用我们的微控制器：

• 用搜索线圈产生脉冲信号
• 将电位计的模拟值与 OPV 的输出信号进行比较
• 通过 LED 和扬声器发出结果信号

我们解决方案的类模型的以下系统模块来自此任务

解决方案所需的库块是已知的。 从对第一个简单解决方案的考虑，我们可以得出以下草稿：

返回目录