ci-server-engineer/knowledge/manuals/IM36K10C10-01EN.md

manual	title	edition	version	status
IM 36K10C10-01EN	Engineering Module - I/O Processes	3rd Edition, Sep. 2023	R1.03	from docs; setup files and default datasets (users, authorization groups, schemes, trigger groups) checked read-only on the test system (2026-09-30)

Engineering Module - I/O Processes (R1.03)

The Engineering Module (Java GUI) defines what CI Server knows: users and rights, sections, items and sub-items, equipment (lines, stations, points, scan types), item statuses, classes, sequences and trigger groups. Section numbers refer to the manual. Command-line equivalents used in this repo are given where they exist (quick load with dssqld, dataset names from dssqld -f).

1. Window (§1)

Menu bar, toolbar, configuration tree (left), work area with property sheets, message area and edit history (undo/redo of edits).

• View → List: List Items (item search), List Objects, item list of a section with values, record layout list.
• Archive: automatic/manual archive, retrieve, mount/initialize/register storage media (history, phase 9).
• Playback: record Engineering Module operations and open the recording viewer.
• Configuration tree areas: sections and items; I/O processing (equipment, classes, …); alarms; reports; history; authorization; references.

2. Authorization (§2)

Login setup lives in dssana.sup (Setup File Editor), on CI Core, so each CI Portal / user interface combination can have its own login method (tab Login control, LOGIN_METHOD = <client>, <user interface>, <method>, <prompt to define users>, <no-login profile>). It also holds single sign-on, Active Directory and password rules (§2.1.1, §2.2).

Login methods:

Method	Behaviour
Automatic	Windows user name = CI Server user name; no password
Manual CI Server	CI Server login form; user must exist in CI Server
Manual OS	Windows login form; with AD on, AD attributes pick the CI Server profile; with AD off the Windows name (without domain) must exist as CI Server user
No	No login; a no-login profile is applied. Only on CI Portal itself, not remote CI View. Protect that profile with a password.
SSO	AD single sign-on, no credentials; if SSO is off in dssana.sup, falls back to Manual CI Server
Deny	The user interface cannot be started

With AD, a user in several groups gets the merged profiles (priority per profile). If no users exist yet, the Engineering Module asks you to define one instead of logging in.

Test system (dssana.sup installed values): local Engineering/Edit Module, Operator Interface etc. use SSO; remote Playback Viewer, Quickload and Display/Symbol utilities are Deny; OPC UA/ODBC use Manual CI Server. The no-login profile named there is CI_NO_LOGIN (the manual says FT_NO_LOGIN, ISS-018); no user of that name exists on the test system. The dssana.sup help says that when the no-login profile does not exist as a CI Server user, full authorization is used (the manual says no profile is applied). Matches the test system: Quickload Utility has No login with an empty profile, and dssqld runs appear in the audit trail as user FULL AUTHORIZATION. Create a restricted CI_NO_LOGIN user before using No login anywhere (IM36K10J40-01EN.md §5).

Enterprise engineers (§2.3) may maintain only their area: sections and everything in them, definitions and deployments, authorization data, and equalization — and can deploy to a server only if they have write rights there (e.g. on ITEM_DF).

Authorization groups (§2.4) (AUTH_GROUP_DF, actions in AUTH_ACTION_DF): a group is a list of allowed actions. Most are <CATEGORY>_<READ|INSERT|MODIFY|DELETE> for a dataset category (e.g. ITEM, SECTION, STATION, CLASS, OBJECT, USER, AUTH_GROUP, TRIGGER_GROUP, HIS_GROUP, REPORT, DISPLAY, ALARM_*, AUD*). Others are single actions, e.g. ITEM_MODIFY_VALUE, ITEM_MODIFY_LIMIT_HIGH, ITEM_MODIFY_BLOCKED_VALUE, ITEM_ACK_ALARM, SECTION_BLOCK_UNBLOCK, STATION_ON_OFF_SCAN, ALARM_CURRENT_ACK, REPORT_GENERATE_ADHOC, SYS_LOG_READ, EXECUTE_GENERAL_COMMANDS, HIS_GROUP_FORCE_ROLLOVER. Installed also: AGGREGATION_OVERWRITE_* (not in the manual). Default groups on R1.03: SYSTEM_MANAGER, ENGINEER, OPERATOR (process areas 1–999) and GUEST.

Users (§2.5) (USER_DF); changes apply at the user's next login. Tabs:

• General: name, description, password (≤ 31 characters, case-sensitive), enterprise user (must be deployed to every CI Core where needed), authorization group, process areas (1–999, lists/ranges like 3 5 8 10-19), locale (en-US, ja-JP; blank = Windows).
• Directory services: AD group mapping and profile priority (higher wins when merging).
• Alarming: alarm selection area, alarm shelving group.
• Operator Interface: logoff timeout (min, 0 = off), deployment folder (default %TLS_WAP_PATH%\cfg\operatorInterfaces\DEPLOY), layout, initial display.
• Destinations: user's report printer for on-demand reports.
• Playback: recording on/off/"HMI Client dependent" (then set in %TLS_WAP_PATH%\cfg\playback\playback.xml per client, application and user), and whether the user may switch recording, change its properties, view, play all users' recordings, export. Default users on R1.03: ADMIN (SYSTEM_MANAGER), ADMINE (enterprise admin), OPER, and CI_NO_LOGIN_OPCUAS (anonymous OPC UA).

Schemes (§2.6) (SCHEME_DF) hide Engineering Module folders and fields a project does not need. Activating one restarts the Engineering Module (OK/Apply do not activate). Tabs: General (multi-language, OPC server, playback, enterprise), I/O processing (PIT filter, STX-Bachmann, hide item statuses), Alarming (e-mail notification, AOI, ASA, first-out, collection, groups, diagnostic flag, OPC AE detection, predefined ack types only), Processing (control item, sequences, priorities, extended reset, predefined trigger groups only), Reporting (item trigger, priorities, lifetime), Historization (external archive, warning time, non-item groups, direct storage), Authorization (process areas, predefined groups only). Installed: STARTER, STANDARD, ADVANCED, none active.

3. Items (§3)

Concepts (§3.1): an item holds value plus conversion, format, alarm parameters, I/O authority, application info and status. Name Section[.Sub-section…].Item, max 255 bytes (multi-byte characters count more). An item can be connected to one I/O point on a station. Raw values are converted to engineering units (e.g. linear f(x)=ax+b from electrical to physical limits; overflow/underflow and a DELTA change limit give statuses; other conversions: IM 36K10L41).

Limits and deadband: up to four limits (none, H+L, or all four) plus one deadband on the normal side; statuses LOWLOW, LOW, NORMAL, HIGH, HIGHHIGH. Scale high/low give OVERRANGED/UNDERRANGED and override limit statuses. Booleans get status TRUE/FALSE (BOOLEAN 1/0).

PIT filter (reduces history events; used only if the application honours it): an update passes when (P OR I) AND NOT T.

• P: |new − reference| > P.
• I: integral of (sample − reference) × seconds > I (1 s resolution).
• T: for T seconds after a pass, nothing passes.
• Each pass sets a new reference.

Sub-items (§3.2): Integrator, Pulse counter (Boolean main item, counts 0→1), Min/Max indicator (runs until reset), Rate of change (time unit day/hour/minute/second chosen per sub-item), Type-less (a free Real item written by PROCESS/REPORT services or applications).

• Integrator: new = (t_now − t_prev) × previous value + old, evaluated every second; negative values subtract. The result is divided by the integration granule itm_int_secs in itm.sup — system-wide, default and test-system value 1 (seconds); 3600 gives hours (answers ISS-010).
• Sub-items have no Equipment tab and are not blocked with their main item.

Defining (§3.3) — right-click node/section → Add. Sections: name cannot be changed (delete and recreate; only possible when empty), new sections are UNBLOCKED; fields Blocked, Visible via OPC, Alarm inhibit, plus read-only parent flags. Nesting is limited by the 255-character path. Blocking a large section can take long.

Item form tabs: General, Item Management, Limits and filtering (not for Boolean), Equipment, Alarm (only if alarming on), Area of interest. Item name (tag): letters, digits, _ recommended; tag and type cannot be changed (delete and recreate).

• General: engineering units, value format (9, 0, +, ., EEEE, date/time codes D DD M MM MMM Y YY YYYY h hh mm ss p, \ escapes a letter), representation (Boolean, Integer 32-bit, Real 64-bit, String), alarming, audit trailing, remember last value immediately (keep value/status/quality over a warm restart instead of NOT INIT), process areas, comment 1/2, map position (WGS 84 latitude/longitude).
• Item management: blocked, OPC visible (+ read/write; also needs the section visible), alarm inhibit, parent flags, data exposure aggregation interval (60 s–7 days, 0 = off).
• Limits and filtering: HH/H/L/LL, deadband (values may be rounded), scale high/low, limit clamping (HH-LL, H-L, scale, none), out-of-range support, trend axis limits, PIT values. String items: max length, default 80. The manual says max 100; the installed software accepts 1–200 and stores length − 1 characters, cutting longer values with status 12 OVERRANGED (verified, ISS-019).
• Equipment: pick an existing I/O point of a station, or define a new point here (created with the item; delete it yourself when deleting the item). No connection = internal item.
• Alarming: OPC AE detection (AE station/event source) or CI Server detection, diagnostic item, acknowledgment type, alarm collection, first-out group/item, delay time, repeat time, per-status alarm state (None, Normal, Alarm 1–3), priority 0–15 (15 highest unless alm.sup inverts it), text, colour, mnemonic, shelve enable. Ack types, collections and first-out groups must exist first.
• Areas of interest: up to 16 labels used to filter alarms.

Blocking and offline (§3.4): blocked (manual, per item/sub-item, nested section or top section) and offline (station connection lost) items are not updated by equipment. Unblocking a section leaves items that were blocked individually still blocked.

Update value (§3.5) (= itmval -p): value, status, quality code, Overwrite blocked (= itmval -o), lock (user/terminal). Option bits (explains the blk/off/uoff/ublk flags of itmval -g, ISS-001):

Bit	Value	Meaning
0	1	Blocked
1	2	Offline (no connection to equipment)
2	4	Updated offline: written by an application (object, this form, itmval) while offline
3	8	Acknowledged (last alarm event)
4	16	Updated blocked: written by an application while blocked
5	32	Direct alarm (alarm state reached, delay running)
6	64	Delayed alarm (after the delay; set together with bit 5)

Also on the form: force to normal / force to alarm, priority, colour, mnemonic, text.

4. I/O processing (§4)

Equipment (§4.1): lines (protocol/connection), stations (controllers, identified internally by equipment manager + slave number; up to 4095 per manager) and points (I/O addresses). Details per station type: IM 36K10L40/L41.

• Station form: line, redundant lines and TCP/IP addresses, preferred line; On scan (off-scan stops input updates for the whole station — cheaper than blocking each item; outputs continue), Suppress outputs, output method (on change / on change and connect); status items: general communication (1 good, 0 bad, status OFFSCAN when off-scan), line 1, line 2 (typeless sub-items show sub-line states for Modbus TCP), line selection.
• Scan types (SCAN_TYPE_DF): name + interval (ms); intervals are multiples of the equipment manager's tick. PLC reads are grouped using maximum gap and maximum size.
• All equipment definitions shows lines, stations, points and scan types read-only; editing is done under each plug-in's own tree node. Points created from an item form are shown as [<item name>].

Item statuses (§4.2) (STATUS_DF): numbers 0–255 mapped to a system text (fixed), description (user text), mnemonic, alarm priority, alarm state, colour, shelve enable. 100–127 are free; the rest are reserved (34–99 and 128+ used for DCS/batch/HAC interfaces). Common ones: 1 CALCULATE, 3 BLOCKED, 4/5 BOOLEAN 0/1, 6 UNDERRANGED, 7 LOW LOW, 8 LOW, 9 NORMAL, 10 HIGH, 11 HIGH HIGH, 12 OVERRANGED, 13 NOT INIT, 14 OFFLINE, 15 UPD OFFLINE, 16 UPD BLOCKED, 21 DELTA, 22 OFFSCAN, 23 OUT_SUPR, 24 BAD VALUE.

Classes (§4.3) (CLASS_DF): templates in the PROCESS Service traditional language (IM 36K10P10) or Java (IM 36K10P11); the language is fixed once created and the two cannot reference each other. Changing a class needs a reset before objects use it.

Sequences (§4.4) (SEQUENCE_DF): a one-off program (class and object in one) tied to a control item; traditional language only. Compile, then set activation time, trigger interval (or trigger once / event-driven TRIGGER on TIMER or ITEM), deactivation time, daylight-saving correction. Blocking the control item puts the sequence off-line; the STEP variable is the control item's value. Classes are preferred for maintainability.

Trigger groups (§4.5) (TRIGGER_DF): name (≤ 15 characters, letter first, then letters, digits, _), activation time (immediate or date), deactivation (infinite or date), trigger once or interval (seconds … years), daylight-saving correction. Triggers fire at activation time + n × interval. Editable except the name; deletable only when unused. Installed defaults: ONCE, ONE_SECOND, TWO_SECONDS, FIVE_SECONDS, TEN_SECONDS, THIRTY_SECONDS, ONE_MINUTE, TWO_MINUTES, FIVE_MINUTES, TEN_MINUTES, THIRTY_MINUTES, ONE_HOUR.

5. Class and object engineering (§5)

Flow: trigger group → class (code, compile) → object → test → (symbol → display → test). PROCESS Service runs at 1-second resolution at best.

• Class (§5.2): name ≤ 15 characters (letter first); language; priority (load balancing, ranges set in the PROCESS Service setup file); Extended reset enabled. Code tab (template, Compile after reopening the form), Listing tab (errors start **** ERROR:; double-click to jump), Trigger Groups tab.
• Object (§5.3): created under a section like an item; node (blank = local / control item's node), priority 0–999 (0 = class priority), class, optional control item (object runs when its status is on-line; BLOCKED disables methods; STEP = its value), map position, up to 99 attribute prompts. Item management: Items may exist (reuse existing items with identical attributes), Leave items (keep created items when deleting the object), blocked, OPC visible, alarm inhibit. Object trigger groups override the class's.
• Testing (§5.4): PRINT statements go to the message log (remove afterwards); right-click object → Debug collects a trace (triggers, methods, changed signals/attributes) shown when debug is switched off.
• Reset (§5.5): compiled changes take effect only after resetting the class (all objects) or single objects; control may be lost briefly; there is no indication which objects were reset. Normal reset for body changes; extended reset when the signature changes (traditional: prolog section; Java: attribute/signal declarations or create()); it may create/modify/delete signal items. If the compiler misses a signature change, force it (Extended reset forced).
• Symbols (§5.6–5.9): a symbol can be tied to a PROCESS Service class; its component properties connect to class signals (e.g. fill colour via a threshold table); on a display each symbol instance is pointed at an object (Edit Module, phase 10).

Differences from the installed software

Logged in knowledge/issues.md; the installed software is taken as right:

• ISS-018: no-login profile CI_NO_LOGIN (manual: FT_NO_LOGIN).
• ISS-019 (closed): string item maximum length is 200 in the software (manual: 100; Tutorial: 168).
• Installed authorization actions include AGGREGATION_OVERWRITE_*, not listed in §2.4.