AWS上的串行COM端口

Question

我正在考虑创建运行工业软件的EC2实例。此EC2实例应该能够从串行COM端口接收数据。是否可以通过串行隧道或其他方式连接类似的东西？

Answer 1

EC2连接是通过网络接口进行的，所以我认为不可能像您所要求的那样进行直接连接。

但是，如果您谈论的是支持自动化的工业设备，则可以使用MQTT或至少使用MQTT桥。如果是这种情况，您可以看看AWS IOT Core

使用AWS IOT Core，您不仅可以在设备与AWS之间建立双向连接，而且还可以提供强大的分析，设备注册和管理功能以及与AWS生态系统的完全集成。

Answer 2

这个问题的答案分为两部分。

1. 是的，从理论上讲，这是绝对可以的。

2. ...但是对于您所想到的特定用途/应用程序/设备，这可能不切实际或不可能。

Terminal servers是该原理的简单说明。请注意，从这个意义上讲，我并不是指Windows远程桌面“终端服务器”，而是指通常称为终端服务器的通用设备，它以最简单的形式是一种物理设备，说一种串行协议，例如一侧为RS-232，另一侧为TCP。 RS-232是PC“ COM”端口的有线协议。

但是，配置了适当驱动程序的计算机可以具有一个“虚拟” COM端口，该端口对计算机上的软件而言就像物理COM端口一样显示为接口，但是该COM端口的驱动程序却可以为软件提供对文字硬件的访问权限实际上是在管理TCP连接，将来自COM端口的发送和接收位通过隧道传输回终端服务器上的物理端口。

终端服务器可以是实际的专用终端服务器设备，可以是全尺寸的PC，具有网络功能的微控制器，具有USB到串行适配器的Raspberry Pi ...可能有很多潜在的变化

要考虑的问题：

许多较旧的工业软件似乎编写得很差。无论如何，这是我的印象。实现者可能会在其专业知识的优势下工作，做出了某些设计假设，这些假设适用于物理COM端口，但可能与此类部署不兼容。如果系统较新并且可以在现代OS上运行，则不太可能是这样，但是在Windows早期以及以前，这确实是一团糟。

许可密钥加密狗（如果存在）可能依赖于物理COM端口的特性，这些特性很难或不可能进行虚拟化。软件许可条款可能会限制您执行此操作。

某些设备可能对所涉及的距离引起的延迟不必要地敏感。例如，我的设施之一和最近的AWS区域之间的Internet路径中有22 ms的往返时间。在9600-8-N-1时，这是传输〜23个字节的时间，这是最好的情况-虚拟化层和加密将增加更多内容。机器或软件的编写可能正确或不够正确，无法接受这种延迟，而这种延迟不会在本地的本地COM端口上发生。

如果要对计算机进行控制（不是简单地观察），则需要通过虚拟化层将计算机与其软件分开，从而绝对确保不会造成安全隐患。

您的插图似乎暗示了在多个EC2实例上通过软件对计算机进行“共享”控制，但这可能会增加一套完全不同的复杂性。

理论上，是可能的。我的意思是，即使Windows远程桌面也允许您share a local COM port使用远程系统，从而允许远程软件访问和控制本地设备。

实际上，这可能需要引起大量注意，这些因素会因操作系统以及相关设备和软件的特定特性而异。