EMAIL

1. EMAIL 5000 Series DATA MANAGEMENT

2. Why Email? • Alarm/Status Notification • Remote unattended sites • Pumping stations • Pharmaceutical/Plant maintenance • Advise Supervisor/ Engineer of failure • Service Initiative • SMS a Eurotherm Service Engineer.

3. Configuring Emails Protocols Status messages Spam mail Embedded Messages Enhancements Servers Email Overview

4. The main email configuration page Every email configured in the system will use the same information for distribution. General Email

5. Mail Server The server to where all the emails will be sent. Can be a known IP address or DNS name. Port Typically 25 unless otherwise stated by your IT administrator Sender Read only field to prevent SPAM. Automatically generated by the instrument. Used for the ‘From’ field in all emails created. General Email

6. Must be configured by the user before any emails can be sent. Should be a valid email address capable of receiving emails. May be the same account for all instruments in a single plant or zone. When an error occurs whilst delivering an email the mail server will want to respond to the sender. As the sender is an instrument not capable of receiving emails the error message must go somewhere. If this is not a valid address the error email will bounce around the mail server indefinitely until deleted by the administrator. All mail server responses (typically errors) will be sent to the ‘Errors To’ address. General Email - ‘Errors To’

7. Only required when the mail server is not on the LAN, and can only be reached by way of a dialup connection. A period of time required to wait for a dialup modem to establish a connection. Timeout with error after this time period if no connection is established. All new emails will be set pending until the timeout has completed. Set to zero by default (assuming LAN based network servers). General Email - ‘Modem Dialup Time’

8. General Email - ‘Modem Dialup Time’

9. Flexibility. The ability to send a single email to a collection/Group of recipients. A maximum of 5 distribution lists available, each allowing 10 recipients. Distribution Lists

10. Each list has a unique descriptor for use throughout the instrument. Not protocol specific. Each list may contain both Email and SMS addresses. Group distribution ‘Cc’ is used to provide better performance. The Hydra only ever creates a single email, and relies on the ‘Cc’ to inform the mail server to duplicate the email. The first good recipient found in the distribution list is used for the ‘To’ component, all other good recipients become ‘Cc’. Any bad recipients in a list are ignored. Operators are informed of any bad recipient addresses at the time of sending the email, giving the list name and recipient number that contains the bad address. Distribution Lists

11. Configuring a single email as follows Configuring An Email

12. Protocol The type of transfer. Subject The content of this field will be used for the ‘Subject’ of the email. Limited to 104 characters. Text The content of this field will be used as part of the body of the email. Placed at the beginning of the body of the email. Limited to 240 characters. Include Message The ability to include an embedded message sequence This will be included after ‘Text’ in the body of the email. Only one embedded message can be included in each email. Configuring An Email

13. Three methods of distributing emails. SMTP - Email SMS - Subject only SMS - Body only Protocol

14. SMTP - ‘Simple Message Transfer Protocol’. Port 25. A standard generic open specification protocol, used by every mail client/server application in the world. Hydra only implements SMTP and MIME V1.0 as standard protocols. Protocol - SMTP (Email)

15. ‘Simple Message Service’ A standard generic open specification protocol predominant in the mobile phone industry. Used to transfer text message data between mobile phones. Hydra does not implement SMS as a protocol, but supports communications with SMS servers. Different network providers support SMS in various different ways, depending upon their server. Subject Only Body only Body and Subject Protocol - SMS

16. An email is built up from several components From To Cc Subject Body An SMS message is created by the serverbased on the content of the SMTP email it receives. However, some SMS servers only use some of the components to create text messages. The ability to communicate with the vast majority of server types. Protocol - SMS

17. Uses content of ‘Subject’ to create the body of the text message. This may also be truncated to 60 characters on some older servers. Protocol - SMS (Subject Only)

18. Uses content of ‘Body’ to create the body of the text message. This may also be truncated to 160 characters on some older servers. Or a collection of multiple text messages. Protocol - SMS (Body Only)

19. New mail servers are much more advanced. The entire email is converted to SMS and the text message may even include all components. Use SMTP (Email) for these servers. Protocol - SMTP (Body & Subject)

20. Emails can only be sent via a job. Only one email can be sent by any one job, and to only one distribution list. Sending Emails

21. No dedicated diagnostics. Status messages inform the user what is going on. A status message is sent to each group, therefore a status messages can be viewed from any group display or the message log. All status messages are given a ‘General’ category. All status messages will be pre fixed with the current time/date stamp. Where possible each status message will contain the email descriptor and distribution name for better context. Status Messages

22. The following is a list of possible status messages. Sent {0} to {1} Error creating embedded message sequence Unable to connect to mail server Mail server not found (unable to resolve DNS) Failed to open socket to a mail server Invalid recipient address found in {0} Mail server rejected introduction Invalid ‘Errors To’ address Invalid recipient address Mail server rejected data Mail server rejected email Socket write fail occurred The maximum pending emails have been reached, {0} will not be processed. For more information please contact your supplier. Status Messages

23. This implementation makes use of RFC2822 & 821 which lays out the standard for the Internet Message Format. RFC2822 implies that at a very least the following fields must be included in the header section: Correctly formatted time/date the email was created. A valid address or name of the sender, not necessarily the author. A valid From address specifying the author of the email, this author SHOULD be a valid email address capable of receiving emails, in our case this will be the ‘Errors To’ field. Unique message Id’s No guarantee can be made, that the email generated by the instrument will not be interpreted as a Spam message by the receiving server. Spam

24. Extended for use with email. The following are new embedded fields: Source alarm data Specified alarm data Batch status Batch field data Instrument number Instrument name Configuration Revision Not email specific, new fields are available to the entire product. Embedded Messages

25. The following information is used to create the message for a single source/specified alarm data field, of type absolute high/low Enable Type Threshold Status The data is formatted as follows and placed in the {n} field in the embedded message. The following example shows two embedded fields where field 1 & 2 are alarm 1 & 2 respectively: Source/Specified Alarm Data Field

26. The batch status can be both Group or Instrument wide The data is formatted as follows and placed in the {n} field in the embedded message. The following example shows four embedded fields where field 1,2,3 & 4 are the status of group batch 1,2,3 & 4 respectively: Batch Status Field

27. Any of the 6 fields from any of the current batch's can be used in the embedded message. The following information is used to create the message for a single batch data field: Batch field descriptor Batch field content The following example shows a message containing the status, field 1 & 2 content for Group batch 1: Batch Data Field

28. The following example shows an embedded message containing the following fields: Instrument Name Instrument Number Configuration Revision Other Fields

29. It is important to know where and how to communicate with the mail server, as this is the key objective for the email feature. Server is on local company network (LAN) Using known IP address requires no extra configuration Using DNS name requires DNS server to be configured on the instrument. Failure to do so will result in Unknown host errors, and a lack of communications. Servers - LAN

30. Server can only be reached by remote dialup connection (WAN) The ‘Modem dialup Time’ must be configured to allow enough time for the modem to dialup and establish connection. The router used to initiate the dialup must be configured on the instrument as the ‘Default Gateway’ typically by IP address. Must be on the same network as the instrument. The router must be configured to dialup when SMTP(port 25) packets are received. Typically configure in some rules. The router should be configured to drop the connection after an idle period for efficiency, typically 30 seconds to 1 minute. Using fixed IP address for the mail server requires no other configuration. Using DNS name requires DNS server to be configured on the instrument. It is advisable that the DNS server is on the company network and not required to dialup to this server, as this may force the connection to be held open for long periods of time. Servers - External Network

31. What Next? • V3.3 - January 2004 • Email • Advanced User Screens • CSV Output • Alarm Marks and Meter Banding • Bridge Enhancements • Review - Quick-chart mode - February 2004