Transcript Configuring An Email

EMAIL
5000 Series DATA MANAGEMENT
0
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.
1
Email Overview
• Configuring Emails
• Protocols
• Status messages
• Spam mail
• Embedded Messages Enhancements
• Servers
2
General Email
•
The main email configuration page
•
Every email configured in the system will use the same information for
distribution.
3
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.
4
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.
5
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).
6
General Email - ‘Modem Dialup Time’
5000
(192.168.0.5)
Dial Up To Mail Server
5000
(192.168.0.6)
Wireless Connection
Dial Up To Mail Server
5000
(192.168.0.7)
Modem
(mobile phone)
Access Point
1
2
3
4
SERIAL
DIAL UP ROUT ER - (192.168.0.1)
5000
(192.168.0.8)
Wireless
Modem
Bridge
(mobile
Phone)
11
22
33
44
MDI-X
SERIAL
ETROUT
HERNET
DIAL UP
ER - HUB
(192.168.0.1)
7
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.
8
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.
9
Configuring An Email
•
Configuring a single email as follows
10
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.
11
Protocol
•
Three methods of distributing emails.
•
SMTP - Email
•
SMS - Subject only
•
SMS - Body only
12
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.
13
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
14
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.
15
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.
16
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.
17
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.
18
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.
19
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.
20
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.
21
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.
22
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.
23
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:
24
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:
25
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:
26
Other Fields
•
The following example shows an embedded message containing the
following fields:
–
Instrument Name
–
Instrument Number
–
Configuration Revision
27
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.
28
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.
29
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
30