290 likes | 387 Views
HERA. Large machine! (6.3 Km Proton-electron storage ring, collider) superconducting proton ring, RF cavities => QPS cryogenic control : ~10,000 “channels”
E N D
HERA • Large machine! • (6.3 Km Proton-electron storage ring, collider) • superconducting proton ring, RF cavities => QPS • cryogenic control : ~10,000 “channels” • the “rest”: >10,000 “channels” (>1200 magnet PSCs, ~1000 transient recorders, ~20 warm RF transmitters, 32 collimator jaws, ~1200 vacuum sputter pumps, ~1500 diagnostic monitors, etc.)
1990-1991: “Just get the machine commissioned…” “Worry about an integrated control system later!”
TINE OS IP Stack IPX Stack DOS LWP /Client32 NOVELL Win16 WINSOCK NOVELL Win32 WINSOCK WINSOCK Linux Native BSD Native BSD Solaris Native BSD - HP-UX Native BSD - SGI Native BSD - OSF Native BSD - VAX-VMS UCX - ALPHA-VMS MULTI-NET - VxWorks Native BSD - Three-fold Integrated Networking Environment • multi-platform • multi-protocol • multi-architecture • Data Exchange Architecture: • Client-Server • Publisher-Subscriber • Producer-Consumer • Producer-Subscriber “ansi C - Write once: compile, link, run everywhere!"
TINE Architectures • client-server : • standard, required for commands, synchronous calls • scheduled at client -> asynchronous interrupts at server (inefficient) • easy to program • clients get what they want • scalability: the N client problem • publisher-subscriber: • accepted standard • scheduled at server, efficient • different modes: poll, send on change, asynchronous calls • clients get what they want • harder to program (link tables, etc.) • scalability: the N client problem pushed back
TINE Architectures • producer-consumer: • non-standard - scheduled at server, efficient • clients get what they’re given • easy to program • scalability: no N client problem, no knowledge of clients, • inefficient?, requires subnet or multicast group • producer-subscriber • non-standard - scheduled at server, efficient • different modes: poll, send on change, asynchronous calls • clients get what they want • harder to program (link tables, etc.) • scalability: no N client problem, knowledge of existence of clients • if subnet or multicast group not recognized, fallback to publisher-subscriber
TINE Features • Distributed • Object-based (vs channel-based) • Plug-and-Play • Progressively upgradeable • Strong DOOCS influence • Many Systematics (required vs optional) • Flexible (the ‘herding cats’ problem?) • “Do it yourself”
"I don't want to write code!“ vs “Do it yourself!" (Servers) self-configuring servers … • read configuration database • get IO addresses, hardware information • readout instructions • raw data to finished data (??) • logical name binding or just write the code you need from a "template" • how easy is this?
“I don't want to write code!“ vs “Do it yourself!" (Clients) I don’t have to write code! auto-displaying clients … • widgets query a server for its display properties, • and display them! or just write the display code you need • how easy is this? Yes, but you can’t write code!
"I don't want to write code!“ vs “Do it yourself!" Many control systems allow both approaches non-users of Visual Basic usually offer … • script based display widgets for quick applications • interfaces to C, C++, LabView, MatLab, HPVEE, ... for more complicated applications TINE • Clients typically written in Visual Basic • Servers written in C, C++, Visual Basic, LabView, HPVEE
Visual Basic … • has a large toolkit (ActiveX controls) • is a high-level language (not a script). • has full math library • EASY to program (hey, it's Basic!) What about Java ? • has a large toolkit (Java Beans) • is a high-level language (not a script). • has full math library • VB is still easier to program
TINE GUI Applications … Win32 GUI apps in VB UNIX GUI apps in DDD Java GUI apps (Symantec Cafe) For trivial display applications, the amount of coding in VB is trivial …
TINE Plug and Play • Server registers name and address with name server upon startup • Clients query (and cache) name server for names and addresses • Persistent timeouts force address (re-)resolution ServerName : “HEPORBIT” Export Eqp. Modules “BPMEQM” as “HEPBPM” “BLMEQM” as “HEPBLM” “ALMEQM” as “HEPALM” IP: 131.169.120.43 ENS Where is “HEPBPM” What are your Properties? What are your Devices? … Link to “ORBIT.X”
TINE API • C, C++, VB, Java Client makes a “contract”: full-duplex data “Link” … // TINE Synchronous call (Client-Server) ExecLink(“HEPBPM/WL167”,“ORBIT.X",&dataOut,&dataIn,CA_READ); // TINE Asynchronous call (Publisher-Subscriber) AttachLink("HEPBPM/WL167","ORBIT.X.HIST",&dataOut,&dataIn, CM_POLL,1000,CA_READ,histCallback); // TINE Asynchronous receive (Producer-Consumer) recvNetGlobal(“HEMAGEN”,&dataOut,energyCallback); vs Put(), Get(), PutGet(), Monitor()
TINE Data Types • ~30 different system data types • standard set (BYTE, char, short, (int), long, float, double) • NAME8, NAME16, NAME32, etc. • FLTINT, LNGINT, DBLINT, NAME16INT, etc. • INTFLTINT, NAMEFLTINT, FLTFLTINT, USTRING, etc. • user-defined structures (cross-platform)
TINE Data Acquisition Modes • CM_REGISTER • CM_ CANCEL • CM_ SINGLE (just this once) • CM_ POLL (at regular intervals) • CM_ REFRESH (send on change) • ORed with • CM_ BCAST (send to my subnet) • CM_ MCAST (send to my multicast group)
TINE Data Access Codes • (bit-wise) • CA_READ (default) • CA_WRITE (request to change a setting) • (server only:) • CA_FIRST (coming into scope) • CA_LAST (going out of scope) • CA_HIST (called from the local archive server)
TINE Device Servers • unique export name • one or more instances (device names) • server-specific properties • stock properties • data type and size overloading
Data type and size overloading • Property ORBIT.X is registered to give 300 float values • Device name (e.g. WL167) is use to give the starting • location of the orbit. • Can ask for all 300, 10, or only 1 float value of this property • Can ask for format type CF_FLTINT to get array of • “position-status” pairs, • or CF_NAMEFI to get array of “name-position-status” • triplets.
TINE Security • Servers registered with control system database • Clients anonymous • Open Read Access (from anywhere on the net) • Filtered Write Access thru: • User Name (soft) • Network Address (hard) • Access Lock tokens (very hard)
TINE Alarm System Local Alarm server Alarm API plus local Alarm lists First-level filtering Central Alarm server Collects and filters Alarms Issues post-mortem triggers (A. Kurakin, V. Soloviev, V. Yarygin - ID: 56)
TINE Archive System Local Archive server - Short and Long term histories Central Archive server - long term - filter on machine states - post-mortem events
What’s New? Network subscriptions (Producer-subscriber): - fine-tune (popular) client programs -e.g. images over the net (Fedor Solodovnik : ID 141)
What’s New? DOOCS: - many DOOCS queries, formats - Local Archive Server a la DOOCS - TINE can now run in a DOOCS context! - DOOCS client API - DOOCS GUI Tools
What’s New? EPICS: - EPICS2TINE translation layer - run EPICS on TINE as well as CA TINE naming services TINE systematics make “Composite” properties from channels
What’s New? MKI3: (Wolfgang Gerhardt, et al. ID 124) - Experience in Producer-Consumer mode - no clear-cut way to map MKI3 to TINE - make servers “bi-lingual”
All the control systems you know about work! • So choose one! • Choose a ‘modern’ one (SCADA, DCOM, CORBA)? • Choose a ‘mainstream’ one (EPICS, VISTA)? • Write your own? • sometimes fun or not-so-hard to “re-invent the wheel”, • and at least you get the wheel you wanted! • Out-source?
The Red Queen Syndrome `Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!' - Lewis Carroll, “Through the Looking Glass” XML, SOAP, C#, .NET, … DCOM, SCADA, ActiveX, … JAVA, CORBA , …
Where to use TINE • Multi (Legacy) Platforms important • Multi Architecture important • Shallow learning-curve • No “All or Nothing” requirements http://desyntwww.desy.de/tine