iPlan User Manual

English edition prepared on 9 October 2026 for reservation users and administrators. This manual covers accounts, projects, maintenance, orders, calendar operations, utilization, notifications, and allocation rules. It is based on the supplied Chinese Manual V1.0 dated 9 December 2025, for iPlan V1.3.5 and later. Local implementation notes describe subsequent V1.3.8 changes. Source defaults and permissions should be checked against the installed version. This web edition contains the translated operating instructions.

1 Terms and roles

iPlan manages reservations and allocation of Palladium emulator time, with execution monitoring and utilization reporting. Administrators configure the system and coordinate resources. Regular users request time and manage their own eligible orders.

2 Accounts and sign in

Administrators receive an account initialized by the deployment team. Regular users ask an administrator to create an account and initial password. Where LDAP is configured, users sign in with their directory credentials.

1. Open the organization-provided iPlan address. The source example is http://PlanServer_IP:8770; replace it with your deployment's actual address.
2. Enter the username and password, then select Sign In.
3. If authentication fails, verify the credentials and account status.
4. Select Sign Out at the top right when finished.

For a local account password reset, contact the iPlan administrator. LDAP passwords must be reset through the directory administrator.

3 User administration

Open User Management to create, edit, disable, enable, or delete accounts.

Select New and enter the login name, password, role (user or admin), priority, contact details, daily order limit, and notes. Review and confirm. The source recommends a password containing upper- and lower-case letters, numbers, and special characters; follow your organization's password policy.

Use Edit in the row's actions to update contact information, priority, daily limit, or other editable values. Disable prevents sign-in while retaining records; Enable restores access. The source permits deletion only for users without associated orders. Disable an account when its history must be preserved.

For a batch limit change, select accounts or Select All, choose Batch Update Daily Order Limit, enter the new limit, and confirm. The LDAP settings page handles directory configuration; connection details belong in deployment documentation.

4 Projects and maintenance

Open System Settings > Project Management. Select New, enter the required project name, priority, and notes, then confirm. Use the row's Edit or Delete action to maintain records. Projects with associated orders cannot be deleted under the source's rules. Filter by project name and select visible columns through the page's settings control.

Open System Settings > Device Management for maintenance. Select New and enter the maintenance name, emulator, board list, start and end times, and notes. Review the window and confirm. Edit or delete through row actions; filter by maintenance name and time range.

The source permits maintenance planning within two weeks and blocks maintenance on already allocated time today or tomorrow. Maintenance appears as unavailable capacity in the calendar. The two-week preview does not extend the reservation horizon.

5 Create and manage orders

Open Order Management > New. Complete required fields, marked with an asterisk.

Review and confirm. The source describes an order ID in YYYYMMDDHHMMSS format and priority derived from the user and project. A reservation expresses demand; it does not guarantee capacity. Competing reservations are allowed and are resolved by the selected allocation strategy.

Filter by order ID, user, type, project, state, or model. Select a heading to sort and use settings to choose visible columns. Row actions depend on ownership and state. After Copy, revise the preferred date and time before submitting.

6 States and action meanings

Cancel Order withdraws the request. Cancel Allocation removes assigned time and returns the order to an unassigned state. End makes the order terminal and may trigger backfill of its remaining time.

Users act on their own orders. During the lock, regular users cannot edit orders. After assignment and before execution, detailed source instructions permit only the owner's execution script to be edited. Source wording about editing before allocation is inconsistent; confirm editable fields in the installed UI.

7 Calendar and historical time

Open Time Management, then select a date and emulator. Colored blocks show reservations or allocations. Empty areas show unreserved or unassigned time. Select or drag over a range, then use the context menu. Actions depend on the date, current time, owner, and order state.

For a date before today, View opens read-only details and Copy creates a new request. Update the copy's time preference. Original and backfill orders may occupy the same visible block; use Bring to Front to select which one to inspect. This changes the display, not the scheduling priority.

Today's elapsed time cannot be allocated. For a block spanning the current time, details are read-only; copying is allowed and eligible running orders can be ended early. An attempt to allocate past empty space produces an expired-time message.

8 Administrator actions for today

Administrators can adjust future time and affected orders. Past capacity is read-only and cannot be allocated.

For future allocated blocks, the context menu can offer View, Copy, Cancel Allocation, and End. Detail editing is state dependent. Cancelling allocation frees the block and returns the order to unassigned. Ending an assigned order prevents that order from being scheduled again and can initiate backfill; the original and replacement remain visible in the calendar.

For future Unassigned space, use New Order to create an order that occupies that time directly. Select Order chooses an eligible unassigned order accepting backfill. Review the selected order's details and confirm.

For a running block, eligible orders can be ended before their scheduled finish. The remaining time can be offered to backfill candidates.

9 Administrator actions for tomorrow

Source defaults use today's 16:00 to 17:00 window to allocate tomorrow's capacity. These are configurable times in the deployment's time zone.

Before 16:00, view or edit eligible reservations, copy, or cancel an order. Cancellation makes it cancelled and changes the slot to unreserved. Select or drag over unreserved time to create a new request.

During 16:00 to 17:00, inspect the candidate plan. The default strategy is priority. Administrators can select Priority, Fair Share, or Assignment Rate, then apply Preallocate and review the result.

During the lock, View and Copy remain available. The source permits certain administrator edits but does not support changing assigned time directly in the order-detail form. Cancel Allocation returns the order to locked and unassigned. On unassigned space, New Order or Select Order can be used for eligible requests under the deployment's date rules.

After 17:00, review published assignments. Adjust future allocations, end an eligible order early, or cancel allocation. Ending is terminal and can initiate backfill; cancelling allocation returns the order to unassigned. Create or select eligible orders for remaining capacity where the UI permits.

10 Future bookings and maintenance preview

For dates after tomorrow within the one-week reservation horizon, administrators can view or edit eligible reservations, copy, or cancel them. Create an order by selecting or dragging over unreserved time and choosing New Order.

The second week displays maintenance as Unavailable and does not accept reservations. Selecting an unreserved area there displays the source message that time one to two weeks ahead cannot yet be booked. Dates beyond two weeks are disabled. Confirm precise boundary dates in the installed date selector.

11 Regular user actions for today

Users see occupancy and act on their own eligible orders. Another user's order cannot be edited, cancelled, or ended by a regular user.

For past time, use read-only View, Copy, and Bring to Front where shown. Past empty time cannot be allocated. For the current block, users can end their own running order. It becomes ended and is not rescheduled; remaining time may be backfilled.

For future assigned time, users can view orders, copy them, and edit their own not-yet-running execution script where permitted. They can end their own assigned order before it starts. On future unassigned time, the source permits New Order to occupy the selected capacity directly. Regular users do not have the administrator's Select Order adjustment flow.

12 Regular user actions for tomorrow and later

Before the cutoff, users can view, copy, or cancel their own eligible reservations and create requests on unreserved time. Other users' orders remain outside their edit permissions.

During 16:00 to 17:00, orders are locked against regular-user edits. View and Copy remain available where shown. Selecting unassigned time displays Allocation in progress, please wait.

After 17:00, users can inspect assignments, edit their own assigned order's execution script before execution where permitted, copy orders, and end their own assigned order early. New Order may occupy unassigned time directly.

For later dates in the one-week horizon, users can create reservations and view, copy, or cancel their own eligible requests. The second week's maintenance preview cannot be booked; dates beyond two weeks are disabled.

13 Utilization monitoring

Open Time Monitoring. Administrators select a user and time range to view user utilization, or an emulator model and time range to view device utilization. Regular users see their own utilization trends.

Compare the same time ranges and confirm the report's denominator. Assigned time and observed use measure different things. Collector gaps should be investigated before making a capacity decision.

14 Notifications and Feishu binding

Open Notifications for order-related messages, including start reminders, assignment success, and backfill success. Filter by title and time range. A red dot beside the username indicates unread notices.

1. Add the iplanbot bot in your organization's Feishu client.
2. Open Notifications > Bind Feishu.
3. Enter the account's phone number or email and confirm.
4. Verify successful binding and delivery of a subsequent notice to the bot.

If binding fails, check bot membership and the account identity, then contact an administrator. The source documents Feishu; support for Lark or another overseas channel requires separate integration validation.

15 Allocation and backfill rules

Users reserve within the permitted one-week horizon. The source daily order limit includes the day's requests and older unassigned orders. Competing reservations are allowed. Unallocated orders may become backfill candidates if they accept backfill. Administrators can adjust order priority where policy permits.

The scheduled daily cycle allocates tomorrow's time. Requests submitted after locking do not join that locked cycle. The source describes one scheduled result per day, as well as administrator strategy selection and preallocation during review; these are distinct operations.

Manual ending or a no-show check after the start can trigger backfill. Candidates must accept backfill and fit the hardware and remaining duration. The source manual describes priority ordering and at most one replacement per ended order, using its remaining time. V1.3.8 implementation notes describe an integrated heartbeat processor and weighted backfill ranking. Verify the installed release before relying on the older ranking or replacement limit.

A configured threshold does not guarantee a transition at the exact minute. Background checks and collector freshness also affect when an action occurs.

16 Default configuration

The source configuration path is iplan/configs/server_config.toml. Later implementation documents also describe runtime system settings. Deployed configuration and administrator controls determine actual behavior.

Use the deployment's time zone for these settings. Administrators should validate cutoff, notification, and monitoring behavior with a representative order after changing configuration.

17 Troubleshooting and version checks

Cannot sign in. Check the URL, credentials, and account state. Local password resets go to the iPlan administrator; LDAP resets go to the directory administrator.

Cannot edit an order. Check ownership, state, the lock window, and whether only the execution script is editable. Ask an administrator about unavailable actions.

Order not assigned. Check cutoff inclusion, strategy, model, board capacity, maintenance, preferred time, and competing priorities. Submission does not reserve capacity exclusively.

Cannot book a future date. Confirm the one-week horizon. The second week is a maintenance preview and dates beyond two weeks are disabled.

No backfill. Confirm released capacity, candidate consent, hardware fit, and enough remaining duration. Administrators check heartbeat processing and release-detection settings.

State or utilization is stale. Report the order ID, emulator, time range, and symptom. Administrators check collector freshness, connectivity, and clocks.

Notice missing. Check in-app notices, binding, bot membership, account identity, integration credentials, and notification logs.

Before applying this guide to another release, verify edit permissions, booking horizon boundaries, backfill ranking and limits, daily defaults, and messaging integration. The original manual remains the source for translated procedures; the implementation documentation explains later changes.