ta-vehicle-modeling

TA Vehicle Modeling

Use this only as a thin domain add-on to ty-sysplorer-modeling-rules. The parent skill owns routing, seven gates, layout timing, repair loop, Sysplorer safety rules, and delivery evidence. This skill adds vehicle-domain entry routing, TA six-library vehicle modeling decisions, library boundaries, examples, and validation focus.

Entry Contract

Treat this skill as mandatory for any Sysplorer task whose target object is a vehicle, whole vehicle, automotive subsystem, or vehicle operating scenario, even when the user does not name a TA library.

Trigger examples include:

• Whole-vehicle or subsystem construction, repair, packaging, review, layout-annotation authoring, translation, simulation, or result validation.
• Lumped-parameter, point-mass, equivalent-mass, coast-down, acceleration, braking, drive-cycle, range, economy, handling, ride, thermal-management, engine, battery, electrical-load, chassis, tire, suspension, steering, brake, driveline, powertrain, and motor-drive vehicle tasks.
• Requests that say only "车辆模型", "整车模型", "滑行工况", "动力性", "经济性", "续航", "操稳", "平顺性", "热管理", "发动机", "电池", "低压电器", or similar vehicle-domain wording.

After triggering, first apply ty-sysplorer-modeling-rules for Modelica/Sysblock/hybrid routing. Then use this skill to decide whether the implementation should use TA six-library components, a simpler Modelica/MSL/custom lumped model, or a documented fallback because TA evidence is unavailable or out of scope. Do not skip this skill merely because the user asks for a "simple" or "lumped-parameter" vehicle model.

Hard Constraints

Treat these as blocking requirements, not preferences:

• For Sysplorer vehicle tasks, stay in the Sysplorer MCP / ModelingPy tool domain. Do not route to Syslab skills or Syslab tools unless the user explicitly asks for Syslab.
• Do not directly copy or extends a complete official example, complete vehicle architecture, complete subsystem template, or complete sample deliverable as a new user deliverable.
• Modeling difficulty, missing internal signal wiring, failed repair attempts, or schedule pressure never relaxes the previous rule. If blocked, reduce scope, hand-build the visible topology, or report the blocker; do not hide the requested model behind an inherited complete template.
• Deliverable source must expose the requested vehicle topology through explicit component instances and connect(...) statements unless the task is only to verify or explain an existing example.
• Before CheckModel, TranslateModel, or SimulateModel on a deliverable .mo, run scripts/audit_modelica_source.py when a file path exists. For packaged models, pass --dependency-root with the already authorized top-level package directory so the audit can read enclosing package.mo dependencies; without that option it reads only the model file. Never infer an authorization root or search outside it. A failed audit is a stop condition, not a warning.
• Before simulation, verify that the requested end time is actually bound to the tool/model stop-time setting. Do not use result probe times such as target_time as a substitute for stop time unless the active tool schema documents that mapping.
• Final delivery must state the official/example usage status: reference only, directly reused existing example, or not used. directly reused existing example cannot be reported as a newly built deliverable.
• Apply parent Gate 6 to graphical objects actually created or changed, including automatic layout writes. Use hierarchy, Placement, Line(...), endpoints, and layout diagnostics as structural evidence; image export/inspection follows user needs and available capability. Record not_required for read-only, Documentation-only, code-only without graphical objects, or unchanged graphical targets. Do not expand unchanged inherited levels or claim visual inspection without viewing images.