We configure the connectionstring for NServiceBus persistence as a global setting but that doesn't work for a hosted environment. We can not use the local sql server instances with the same name as they are not available on the containers and we can not use a shared database server either because we do not allow external access to the database server. Bus stops running at the customer can't reach it. What I need is an extension of the bus stop NServicebusconfiguration with properties UseDefaultPersistency , SelectedPersistence, PersistenceConnectionstring.

The bus stops should use the default if no bus stop specific value is configured.

Add support for the OpenProtocol MID 0200 to MID 0225 messages:

• 200 Set external controlled relays

• 210 Status external monitored inputs subscribe (For initial 211, a device with configured External monitored signals is needed!)

• 211 Status external monitored inputs

• 212 Status external monitored inputs acknowledge

• 213 Status external monitored inputs unsubscribe

• 214 IO device status request

• 215 IO device status reply

• 216 Relay function subscribe

• 217 Relay function

• 218 Relay function acknowledge

• 219 Relay function unsubscribe

• 220 Digital input function subscribe

• 221 Digital input function

• 222 Digital input function acknowledge

• 223 Digital input function unsubscribe

• 224 Set digital input function

• 225 Reset digital input function

Imagine the following message flow:

The WorkPerformance received by the OT bus stop triggers a chain of forward actions. The first forward will have all the data from the original WorkPerformance but the second forward action that handles a different upload message does not have access to the data of the original message (WorkPerformance). It would be very convenient to have access to the original data to populate the second forward action.

Extracting data from the original message to separate bus stop variables is cumbersome so being able to set aside the shopfloor message and use it later in forward actions would reduce the configuration effort.

ATS Bus Cockpit (classic) currently connects to the old ATS Bus Data Service which is a .NET Framework WCF service. This service has a few cons compared to the new .NET based data service:

1. It does not work well with Docker which makes it harder to deploy in hosted environments.

2. The service uses self signed certificates and the certificates have to be installed using the netsh tool.

3. It uses the WCF protocol which limits connectivity.

The .NET Data Service is a web API that:

• Offers the same functionality but via different protocols, OData and HTTP instead of WCF.

• Configures it certificates via a configuration file.

• Deploys easily using docker.

• Has a swagger interface to test the API.

• Supports the web based front-end.

Development on the old ATS Bus Data Service will stop and therefore ATS Bus Cockpit (classic) has to connect to the new .NET Data Service using OData and HTTP for as long as the web based configuration tool is not released.

The OT socket channel currently processes the following data formats:

• Binary

• Text

• CSV

A format that the channel should be able to process is XML because there are networked devices like the Mettler Toledo weighing scales that exchange XML formatted messages via a socket connection.

The description of the ATS Bus windows services are not very descriptive. The descriptions should explain where the services are used for:

ATS Bus Linux deployments (images) should only use lower case characters and no whitespaces in file and directory names.

All new versions of ATS Bus will be deployed as 64-bit applications to:

• improve performance

• increase the amount of addressable memory

First the OT and ADOS bus stop will be migrated to 64-bit services followed by the IT bus stop.

ATS Bus 1.x and 2.x use port numbers 8700 - 8710 and 8800 - 8810 for the Data Service and bus stop endpoints. These port numbers conflict with the ATS Inspect CAD Report and CAD Conversion services. Newer versions of ATS Bus will use port numbers starting from 9700 for their endpoints. The data service endpoints will start from port 9700 and the bus stops will start from port 9710.

ATS Bus 2.7 supports MSMQ and RabbitMQ message transports. ATS Bus 2.8 adds message transports via SQL Server tables, Azure Storage queues and the Azure service Bus.

All RESTful API’s (monitoring, work order manager, bus stop configuration and security manager) in ATS Bus are encrypted using a certificate.

The PLC channel will support the EthernetIP protocol to be able to communicate with Allen Bradley PLC's without the use of an OPC server.

"ATS Bus will receive a mechanism that allows users to drop files in a directory that is managed by a channel. The channel is configured just like any other channel in ATS Bus and messages (containing an attachment) can be published on the bus where other bus stops can subscribe to. The subscribers can then receive the attachment and store or process it.

The initial functionality will allow users to drop files in a directory where a bus stop publishes it on the bus. Subscribers then configure another channel to enable them to store the attachment in a specified directory. These channels will at least be able to archive files and extract metadata from it that will be used when publishing the attachment. "

Current versions of the bus stops receive their configuration via a WCF interface. WCF will become obsolete so this should be refactored to a REST interface. Doing this is a first step migrating the bus stops to a .NET core version.

"The OT bus stop allows any OT channel message to be forwarded to the OPC UA server channel but doing this may affect the performance of the OT bus stop and OT bus stop persister when forwarding a high volume of messages to the OPC UA server channel.This mainly affects the deduplication mechanism that persists 'outbox' data to the persister.

The OT bus stop should be equipped with an additional OPC UA server that exposes all OT bus stop channel messages when configured to do so. The channel messages should be have a flag informing that its data should be exposed to the additional OPC UA server. This allows the customer to connect an OPC UA client to monitor all channel message values in near real time. "

"ATS Bus should not only use the ATS Security Manager for authenticating user for front-end application but it must also be used to authenticate user that use the following services:

• OT bus stop work order manager REST API

• OT bus stop web service

• IT bus stop web service"

The ATS Bus applications and services have the ATS Security Manager endpoint stored locally instead of a central location. The global settings in the ATS Bus configuration database is a perfect location to store this information.

"The OT bus stop comes with a front-end application that allows the user to view, close and reset work orders in the OT bus stop. A REST API should be made available that offers the same functionality. The REST API allows users to integrate the work order manage functionality in third party applications.

The REST API should authorize users via the ATS Security Manager and maintain a secure/encrypted connection between the REST client and service."

The bus stops currently persist subscription, saga and outbox data to RavenDB and a SQL Server using NHibernate. The NHibernate persister was implemented because there was no native SQL persister at that time. Today, a native SQL persister is available and it should be implemented. The SQL persister persists outbox, subscription and saga data in separate tables which the NHibernate persister does not do. Another benefit of SQL Persistence over RavenDB is that most IT departments are more familiar with SQL Server than with RavenDB.

"## Direct Connectivity to SAP

The SAP connector provides ATS Bus with the possibilities to

• Receive masterdata from SAP via IDocs like material information, bill of materials

• Receive e.g. orders, inspection lots and mateial batch information from SAP

• Book order confirmations, upload test results and create material movements in SAP via IDocs and function calls

"

The ADOS, Cloud and IT bus stop should be able to process B2MML Material and Product Definition information models. These data models are used to exchange master data between various IT systems (MES/ERP/PLM)

"The PLC channel allows OT bus stop users to exchange data with a Siemens S7 PLC. The PLC channel connects to the PLC using an IP address and a rack/slot value. Customers noticed that the read speed could be improved and they also noticed that the PLC channel cannot connect to the PLC using local/remote TSAP addresses. The PLC channel should add an option to configure the local and remote TSAP and variables should be read using block reads where possible to speed up the read speed. "

"The OT OPC client channel should be able to connect to a redundant OPC UA and DA server and fail over when:

• The keep alive signal is missed.

• A preconfigured OPC tag's quality goes to a value other than Good (192)

• A preconfigured OPC tag's value matches an expression (Value = A, Value <= A, etc)"

"The ADOS Inspect channel is able to receive ATS Inspect Inspection, Defect, Repair, Tracking and UnitQuestion events. These events are validated against embedded XML schemas and will not be processed if the validation fails.

Customers requested the possibility to disable the validation because the content of the Inspect event may vary per site.

Another customer request is to support the DefectQuestion node that is embedded in the Defect event's Defect node.

The ATS Inspect event handling should be updated:

• The user should be able to enable (opt-in) the event validation, the ADOS Inspect channel should disable the validation by default.

• The ADOS Inspect channel should convert the DefectQuestion node to B2MML so that it can be processed in other bus stops."

"The OT Bus Stop can use a direct connection to Siemens PLC of type S7 to collect data and to send data to the PLC. This eleminates the need of a seperate OPC server for the communication which reduces complexity and costs. See Manage PLC Channels for a documentation of the functionality "