Project_Data.mdb
Used to store all FCS related data, also used to submit
"batch style" jobs for unmonitored import and processing (typical
size for a 20 FCS project =300MB).
Project_Graphic.mdb
Used to store all ICS/PICS stuff, including trends, graphics,
security. Can be used stand alone or called from Project_Data.mdb
(typical size for a 20 FCS project = 150MB).
Project_Xref.mdb
Can be called either manually or from Project_Data batch
jobs. Stores cross referenced tables built from data
in Project_Data & Project_Graphic. Pretty handy
for lookups.
Project_TuningData.mdb
Can be called manually or as part of Project_Data.
Builds lookup tables for Tuning parameters, also provides
"Changes" reporting (in conjunction with Project_TuningLocal.mdb)
if required.
Project_AlarmLog.mdb
Provides facilities and tools for importing and processing
the PICS/ICS binary alarm logs and storage and archive of
alarm data. Requires Project_Data.mdb to be available
and up to date (at least once) - but if required I can remove
this requirement. Allows alarms to be collated selectively
from consoles, ie; system alarms from all, but only process
alarms from assignment masters. Note; Centum CS has
an unsavoury feature whereby it timestamps alarms at the console,
which on a large distributed system, means that combining
an alarm log sourced from several places means you get several
instances of the same alarm at different times.
Project_Trend.mdb
Allows trend data (stored on consoles) to be converted
in access tables, with configurable frequency and storage
durations. This can be used in place of long term trending
if required - and you have the storage space. Ideal
improvements would include compression, differential storage,
and standard SPC, ie; min, max, avg, std, calculations etc.
I haven't used this for a while but I'm pretty sure it can
stand by itself.
Project_Calcu.mdb
Runs in conjunction with Project_Data - provides users
with a LOGIC chart viewer for CALCUs. Pretty neat really,
check out the example (attached). Also provides a diagnostic
page for FCS block and alarm status (attached) - only bug,
which I'll address when there's a need, is that the FCS disgnostic
page for overloaded FCSs (ie; 1000+ function blocks), can't
handle the size. The solution is to split it to several
pages.
Project_Integrity.mdb
A series of
really basic tests for the FCS projects - which don't seem
to be in the Yokogawa tool set, ie; dud graphic tags on mimics,
switches in software not used, written to from two places,
alarms disabled in detail spec & used as interlocks, alarms
used as interlocks and disabled in tuning parameters, etc.
Guaranteed to generate heaps of work for any quality conscious
control engineer.
Project_Logger.mdb
A work in progress
- hardcoded references etc, nevertheless, uses TCP/IP sockets
to communicate with a Centum Gateway & read tags and store
in the same structures as the Project_Trend storage.
Needs heaps more work - especially on working the bugs out
of the gateway link - suffers due to tardiness on the part
of the gateway.