1. 0 EMAIL 5000 Series DATA MANAGEMENT

2. 1 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. 2 Email Overview Configuring Emails Protocols Status messages Spam mail Embedded Messages Enhancements Servers

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

5. 4 General Email 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.

6. 5 General Email - ‘Errors To’ 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.

7. 6 General Email - ‘Modem Dialup Time’ 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).

8. 7 General Email - ‘Modem Dialup Time’

9. 8 Distribution Lists 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.

10. 9 Distribution Lists 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.

11. 10 Configuring An Email Configuring a single email as follows

12. 11 Configuring An Email 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.

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

14. 13 Protocol - SMTP (Email) 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.

15. 14 Protocol - SMS ‘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

16. 15 Protocol - SMS An email is built up from several components –From –To –Cc –Subject –Body An SMS message is created by the server based 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.

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

18. 17 Protocol - SMS (Body Only) 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.

19. 18 Protocol - SMTP (Body & Subject) 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.

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

21. 20 Status Messages 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.

22. 21 Status Messages 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.

23. 22 Spam 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.

24. 23 Embedded Messages 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.

25. 24 Source/Specified Alarm Data Field 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:

26. 25 Batch Status Field 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:

27. 26 Batch Data Field 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:

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

29. 28 Servers - LAN 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.

30. 29 Servers - External Network 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.

31. 30 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