ci-server-engineer/knowledge/manuals/IM36K10C10-01EN.md
cliu 58a7ed826e Record phase 13 manuals, progress, ISS-018 answer and issues ISS-053/054
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 19:12:45 +10:00

251 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
manual: IM 36K10C10-01EN
title: Engineering Module - I/O Processes
edition: 3rd Edition, Sep. 2023
version: R1.03
status: 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.