Re: [foxboro] Alarm Capture

Unfortunately the legacy Historian does not store process alarms in the
Informix database like it does for System Monitor or Operator Action Journal
messages. The only way to get to the alarm history is through the "almhist"
circular file. There are also other problems such as duplicate or missed
messages. It's not a perfect solution.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Sieling, Marcel
Sent: Tuesday, March 23, 2004 7:07 AM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] Alarm Capture


Hi,

GOP wrote:
> PAS- PlantState Suite can connect to FoxHistory or=20
> AIM*Historian using ODBC but their solution for=20
> Legacy Historian is 'ftp' .=20

This is for my opinion just a hack, which runs a script from the =
crontab
periodically which actually grabs the historian circular files and =
cranks
them through some script which changes it to a plain ASCII format which =
is
then transferred via ftp to the server, where dupes have to be =
eliminated
while feeding them into the database.

Our solution with an OLE-DB interface is realtime and dupe-free.

> As you mentioned, our primary intention is replacement for=20
> the printers and real time update on screen . Alarm Analysis=20
> is secondary .  FTP'ing  will not serve ourpurpose.=20

Correct.

Best regards -

Marcel Sieling
Systems Technologies

Invensys Systems GmbH
Heerdter Lohweg 53 - 55
40549 Duesseldorf
Germany
Tel.:  +49-211-5966-171
Fax:  +49-172-50-2673077
Mobile:  +49-172-2673077
Email: mailto:msieling@xxxxxxxxxxx=20
Homepage: http://www.invensys-process-systems.de=20
Visit my private homepage: http://www.powerslider.de


> -----Urspr=FCngliche Nachricht-----
> Von: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von gop@xxxxxxxx
> Gesendet: Dienstag, 23. M=E4rz 2004 09:37
> An: foxboro@xxxxxxxxxxxxx
> Cc: 'foxboro@xxxxxxxxxxxxx'
> Betreff: Re: [foxboro] FW: Alarm Capture
>=20
>=20
> =20
>=20
>=20
> PAS- PlantState Suite can connect to FoxHistory or=20
> AIM*Historian using ODBC=20
>=20
> but their solution for Legacy Historian is 'ftp' .=20
>=20
> As you mentioned, our primary intention is replacement for=20
> the printers and real time=20
>=20
> update on screen . Alarm Analysis is secondary .  FTP'ing =20
> will not serve ourpurpose.=20
>=20
> Gops=20
>=20
> Aramco Mobil Refinery=20
>=20
> ----- Original Message -----=20
>=20
> From: "Pan, Jim" <Jim.Pan@xxxxxxxxxxx>=20
>=20
> Date: Monday, March 22, 2004 9:48 pm=20
>=20
> Subject: Re: [foxboro] FW: Alarm Capture=20
>=20
>=20
>=20
> >
> >PlantState Suite software supports all versions of Historians,
> >including:* legacy Historian=20
> >* FoxHistory=20
> >* AIM*Historian=20
> >* FoxAMI=20
> >
> >There is a requirement of 2nd Ethernet connection. The ODBC driver
> >or OPC=20
> >server is not required for collecting messages from legacy=20
> Historian.=20
> >
> >If your goal is to view alarm history in real-time mode then the
> >printer-port alarm capturing products should suite your need. If=20
> >your goal=20
> >is to analyze the alarms (optionally for alarm optimization) then=20
> >you should=20
> >focus on alarm historization and event analyses=20
> capabilities, not the=20
> >real-time displays.=20
> >
> >Jim Pan
> >
> >
> >-----Original Message-----
> >From: foxboro-bounce@xxxxxxxxxxxxx=20
> >[foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of gop@xxxxxxxx=20
> >Sent: Monday, March 22, 2004 12:10 PM=20
> >To: foxboro@xxxxxxxxxxxxx=20
> >Subject: [foxboro] FW: Alarm Capture=20
> >
> >
> >
> >All such programs capturing alarms from the Alarm History through
> >the=20
> >
> >TCP/IP port require AIM*AT packages in the I/A side (ODBC,OPC
> >server).=20
> >
> >We are still using Legacy Historian and interfacing this with the
> >
> >external world is not easy . By capturing from the printer port,
> >the=20
> >
> >alarms could be displayed in real-time mode , whereas reading from
> >the=20
> >
> >Alarm History could not give a real-time display. The only
> >bottleneck=20
> >
> >is sending the Alarm priorities to the printer , without the need
> >for=20
> >
> >reconfiguring the priorities again in the capture program.
> >
> >
> >
> >Thanks &Regards,
> >
> >GOPS
> >
> >Aramco Mobil Refinery
> >
> >
> >
> >-----Original Message-----
> >From: foxboro-bounce@xxxxxxxxxxxxx [foxboro-bounce@xxxxxxxxxxxxx] On =

> >Behalf Of Sieling, Marcel=20
> >Sent: Monday, March 22, 2004 2:03 PM=20
> >To: 'foxboro@xxxxxxxxxxxxx'=20
> >Subject: [foxboro] Alarm Capture=20
> >
> >
> >
> >Hi list,
> >
> >
> >
> >GOPS wrote:
> >
> >>Is there a way to customize the format in which the alarm=3D20
> >
> >>printers print ? Can we include the alarm priority as well in the
> >=3D
> >
> >printout
> >
> >?=3D20
> >
> >>How does the printer recognize 1st priority alarms =3D20
> >
> >>and print them in a different color ? If this is a printer=3D20
> >
> >>command, could we extract this information from the=3D20
> >
> >>COM ports ?=3D20
> >
> >
> >
> >We investigated this problem because one of our big customers
> >here=3D20=20
> >
> >in Germany had the same requests. They even stronger wanted to=3D20
> >
> >collect all alarm messages from their 22 I/A-Systems in one
> >central=3D20=20
> >
> >database and examine them there with a commercial tool.
> >
> >
> >
> >We offered them a combined solution using the state of the art=3D20
> >
> >Solution "PlantStateSuite" from PAS (http://www.pas.com) to=3D20
> >
> >rationalize, analyze and report all kinds of statistical analisys
> >=3D=20
> >
> >reports=3D20
> >
> >based on any kind of message data (Alarms and Operator Action)=3D20
> >
> >and a software package we will develop here in germany which=3D20
> >
> >provides an OLE-DB interface from the I/A Alarm Manager
> >directly=3D20=20
> >
> >to an SQL server via a network link. The Alarm Messages are=3D20
> >
> >transferred in a structured manner, so no need to parse byte=3D20
> >
> >streams. All information available in the alarm system is
> >transferred=3D20=20
> >
> >with this solution. In that interface the following information
> >will be =3D=20
> >
> >
> >
> >transferred directly from the Alarm Messager without COMM=3D20
> >
> >processors and their serial interfaces and the parsing of string
> >data.=3D20=20
> >
> >
> >
> >The data structure is as follows:
> >
> >
> >
> >typedef struct ALARM_NEW_MSG
> >
> >{
> >
> >short messg_type;
> >
> >char date_time[DATE_TIME_LENGTH];
> >
> >char letterbug[LETTERBUG_LENGTH];
> >
> >char compound_name[COMPOUND_NAME_LENGTH];
> >
> >char block_name[BLOCK_NAME_LENGTH];
> >
> >char point_name[POINT_NAME_LENGTH];
> >
> >char alarm_type_msg[ALARM_TYPE_MSG_LENGTH];
> >
> >short pnt_no;=3D20
> >
> >short sct_no;=3D20
> >
> >short opr_err;=3D20
> >
> >char parameter_name[PARAMETER_NAME_LENGTH];
> >
> >char tenths; =3D20
> >
> >char inhprt; =3D20
> >
> >char id_length; =3D20
> >
> >char dummy[DUMMY_LENGTH];=3D20
> >
> >char ack_state;=3D20
> >
> >short monotonic_time;=3D20
> >
> >short valid_time;=3D20
> >
> >short priority;=3D20
> >
> >short stepno;=3D20
> >
> >char subrno;
> >
> >char sbxno;=3D20
> >
> >float alarm_limit;=3D20
> >
> >float real_value;=3D20
> >
> >short block_dscrp_length;=3D20
> >
> >short msg__text_length;=3D20
> >
> >short in_out_length;=3D20
> >
> >short units_length;=3D20
> >
> >short state_text_length; =3D20
> >
> >char text_buffer[LENGTH_LEFT];
> >
> >} ALARM_NEW_MSG;
> >
> >
> >
> >The software is not ready yet and will be produced and sold as
> >a=3D20=20
> >
> >commercial product if customers are interested. We expect it to be
> >
> >Ready in a few weeks in case there is a request.
> >
> >
> >
> >In case you need more information or in case you are interested
> >feel=3D20=20
> >
> >free to contact me directly, I'd be glad to answer any questions,
> >if I =3D=20
> >
> >can.
> >
> >
> >
> >Best regards -
> >
> >
> >
> >Marcel Sieling
> >
> >Systems Technologies
> >
> >
> >
> >Invensys Systems GmbH
> >
> >Heerdter Lohweg 53 - 55
> >
> >40549 Duesseldorf
> >
> >Germany
> >
> >Tel.: +49-211-5966-171
> >
> >Fax: +49-172-50-2673077
> >
> >Mobile: +49-172-2673077
> >
> >Email: msieling@xxxxxxxxxxx=3D20
> >
> >Homepage: http://www.invensys-process-systems.de=3D20
> >
> >Visit my private homepage: http://www.powerslider.de
> >
> >
> >
> >
> >
> >>-----Urspr=3DFCngliche Nachricht-----
> >
> >>Von: foxboro-bounce@xxxxxxxxxxxxx=3D20
> >
> >>[foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von gop@xxxxxxxx
> >
> >>Gesendet: Samstag, 20. M=3DE4rz 2004 11:25
> >
> >>An: foxboro@xxxxxxxxxxxxx
> >
> >>Betreff: [foxboro] Alarm Capture
> >
> >>=3D20
> >
> >>=3D20
> >
> >>=3D20
> >
> >>Is there a user option to configure the alarm printouts in Fox
> >I/A ? =3D
> >
> >
> >
> >>=3D20
> >
> >>The alarm printing format is embedded somewhere in the base=3D20
> >
> >>software .=3D20
> >
> >>=3D20
> >
> >>We have tested various alarm capture packages to convert the=3D20
> >
> >>alarm text dump to useful data,=3D20
> >
> >>=3D20
> >
> >>but so far we could not come up with a perfect solution .=3D20
> >
> >>There are ways to extract the alarms=3D20
> >
> >>=3D20
> >
> >>from the Alarm History using AIM*AT packages , but this is=3D20
> >
> >>not good replacement for the=3D20
> >
> >>=3D20
> >
> >>real-time alarm printers . At the same time , alarms captured=3D20
> >
> >>from a printer port does not=3D20
> >
> >>=3D20
> >
> >>contain alarm priority , which is an important information=3D20
> >
> >>for analysis.=3D20
> >
> >>=3D20
> >
> >>Is there a way to customize the format in which the alarm=3D20
> >
> >>printers print ? Can we include=3D20
> >
> >>=3D20
> >
> >>the alarm priority as well in the printout ? How does the=3D20
> >
> >>printer recognize 1st priority alarms=3D20
> >
> >>=3D20
> >
> >>and print them in a different color ? If this is a printer=3D20
> >
> >>command, could we extract this=3D20
> >
> >>=3D20
> >
> >>information from the COM ports ?=3D20
> >
> >>=3D20
> >
> >>________________=3D20
> >
> >>=3D20
> >
> >>Thanks &Regards,=3D20
> >
> >>=3D20
> >
> >>GOPS=3D20
> >
> >>=3D20
> >
> >>Aramco Mobil Refinery=3D20
> >
> >>=3D20
> >
> >>=3D20
> >
> >>______________________________________________________________
> >
> >>_________
> >
> >>This mailing list is neither sponsored nor endorsed by=3D20
> >
> >>Invensys Process Systems (formerly The Foxboro Company). Use=3D20
> >
> >>the info you obtain here at your own risks. Read=3D20
> >
> >>http://www.thecassandraproject.org/disclaimer.html
> >
> >>=3D20
> >
> >>foxboro=3D20
> >
> >>mailing list: http://www.freelists.org/list/foxboro
> >
> >>to subscribe: =3D20
> >
> >>foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
> >
> >>to=3D20
> >
> >>unsubscribe: =3D
> >
> >foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> >
> >>=3D20
> >
> >>=3D20
> >
> >
> >
> >
> >
> >_____________________________________________________________
> __________
> >
> >This mailing list is neither sponsored nor endorsed by Invensys
> >Process=20
> >
> >Systems (formerly The Foxboro Company). Use the info you obtain
> >here at=20
> >
> >your own risks. Read
> >http://www.thecassandraproject.org/disclaimer.html=20
> >
> >
> >
> >foxboro mailing list:
> >http://www.freelists.org/list/foxboro=20
> >
> >to subscribe: foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> >
> >to unsubscribe: foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> >
> >
> >
> >
> >_____________________________________________________________
> __________
> >This mailing list is neither sponsored nor endorsed by Invensys=20
> >ProcessSystems (formerly The Foxboro Company). Use the info you=20
> >obtain here at=20
> >your own risks. Read=20
> >http://www.thecassandraproject.org/disclaimer.html=20
> >foxboro mailing list:=20
> >http://www.freelists.org/list/foxboroto subscribe: foxboro-=20
> >request@xxxxxxxxxxxxx?subject=3Djointo unsubscribe: foxboro-=20
> >request@xxxxxxxxxxxxx?subject=3Dleave=20
> >
> >
> >_____________________________________________________________
> __________
> >This mailing list is neither sponsored nor endorsed by Invensys=20
> >ProcessSystems (formerly The Foxboro Company). Use the info you=20
> >obtain here at=20
> >your own risks. Read=20
> >http://www.thecassandraproject.org/disclaimer.html=20
> >foxboro mailing list:=20
> >http://www.freelists.org/list/foxboroto subscribe: foxboro-=20
> >request@xxxxxxxxxxxxx?subject=3Djointo unsubscribe: foxboro-=20
> >request@xxxxxxxxxxxxx?subject=3Dleave=20
> >
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:        =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>=20
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: