Assessment 1 — Battery Swap Rack
1. Overview of Assessment
Assessment 1 is an individual report worth 30% of the overall grade. Across Weeks 1–5 you will build a Systems Engineering (SE) concept package for an electric scooter battery swap rack to be deployed at a single pilot site in Ho Chi Minh City.
The rack must deliver safe, rapid, and traceable battery exchanges for private scooter owners who rely on two-wheel transport for commuting and daily errands. Battery assets are owned, maintained, and cycled by the swap operator, riders lease charged packs on demand after paying a refundable security deposit and return depleted ones.
The client (codename Project Saffron) is a rapidly growing Vietnamese electric-mobility manufacturer preparing to launch a premium smart scooter line. They need a swap rack concept that can scale across Ho Chi Minh City. While the brand remains confidential, assume expectations typical of a leading Vietnamese OEM launch and design accordingly.
Your rack design must integrate with the client-specified S-Series swappable battery module (baseline data: LFP chemistry, 3.5 kWh capacity, approx. 6 h full charge, IP67 ingress rating, durability to 70% capacity after ~2,000 cycles, assumed pack mass ≈11 kg) and support approximately 500 swap transactions per 24-hour period while maintaining safety and service quality. The assessment focuses on the single rack unit that enables users to deposit batteries needing a charge and swap them with a fully charged replacement battery, you may reference broader ecosystem implications only where they clarify design decisions.
Focus your analysis on the street-facing pilot rack (e.g., District 1) that operates continuously. Riders approach the rack, authenticate via NFC/QR, place their depleted pack into an intake port, and immediately receive a charged pack from the rack. Behind the scenes the system conducts safety diagnostics, queues depleted packs for charging, balances grid demand, and reports status to a remote control centre. Capture both the on-site rider experience and the automated back-of-house functions (diagnostics, charging, staging, monitoring) that keep the rack running 24/7.
Your submission should evidence your understanding of Weeks 1–5 materials on context definition, requirements, and high-level design, aligned with the Systems Engineering V Lifecycle process.
2. Assessment Task
Prepare a professional SE concept report (approx. 2,500–3,000 words including figures and tables). Structure your submission using the sections below, indicative lengths are guides only, but each element must be addressed.
| Section | Focus | Indicative length |
|---|---|---|
| Executive summary | Opportunity overview, key recommendations, summary risks/benefits. | ≈200 words |
| Stakeholder & problem definition | Stakeholder map, system-of-interest boundary, rider journey context diagram, key assumptions, regulatory and occupational safety summary (aligned with Vietnamese HSE expectations). | ≈400–500 words |
| Concept of Operations | End-to-end rack workflow (arrival → authentication → swap → departure) plus supporting automated functions, with at least two critical use cases (e.g., peak commuter rush, pack fault) using the techniques introduced in Week 3 tutorials. | ≈500–600 words |
| Requirements development | ≥8 SMART user requirements and ≥12 derived system requirements covering throughput, battery handling, safety, customer experience, and compliance. Include a concise traceability matrix and planned verification method (one line per requirement). | ≈500–600 words |
| Functional & high-level design | Level 0–1 functional hierarchy plus the functional flow approach practised in Week 4 workshops, comparison of at least one alternative rack concept with trade-off rationale, and a summary of key interfaces. | ≈450–550 words |
| Integration & development planning | Lifecycle plan (concept → pilot launch) aligned with Week 5 lifecycle planning material, traceability/MBSE approach, top risks/assumptions, and handover pointers for Assessment 2. | ≈300 words |
| Reflection on SE practice | Personal insights on applying course methods and preparing for team deliverables. | ≈150 words |
Refer to the sample context diagram, Concept of Operations table, and traceability matrix provided in the Week 2 and Week 3 Canvas activities; adapt those patterns for your submission as needed.
Appendices may contain supporting calculations, risk/assumption logs (as introduced in Week 5), stakeholder notes, or detailed diagrams, cite them in the main text so assessors can locate evidence quickly.
3.1. Project Saffron Clarifications
The following question-and-answer brief has been supplied by Project Saffron to frame expectations for the pilot rack. Use these responses to refine stakeholder needs, derive requirements, and inform architectural trade-offs.
| Question | Client Response |
|---|---|
| What daily throughput should the rack guarantee? | Minimum 500 swaps in any 24-hour window with service availability above 98%. |
| What operating hours are required? | Full 24/7 availability with automated failover and remote restart capability. |
| What physical footprint is acceptable at the pilot site? | Maximum 20 m² including queuing lanes; overall height must remain below 3.2 m to comply with signage bylaws. |
| Are there structural loading constraints? | Assume slab-on-grade capacity of 5 kN/m²; heavier loads must be distributed via integrated base frame. |
| What ambient conditions must be tolerated? | Outdoor operation from 10–45 °C, up to 95% RH, monsoonal rain, and coastal salt spray per TCVN exposure categories. |
| What ingress protection rating is required? | Minimum IP55 for enclosure doors; battery handling actuators must meet IP65. |
| How should riders authenticate? | Provide NFC membership card tap plus mobile QR fallback; system must continue operating offline for up to 30 minutes. |
| How will riders pay for swaps? | Swap fees are deducted from a pre-paid wallet; rack must integrate with Project Saffron’s payment API via REST/JSON. |
| Can the rack accept non S-Series packs? | No. Only certified S-Series packs with embedded RFID tags are permitted; mismatched packs must be rejected automatically. |
| What charging infrastructure is available? | Three-phase 415 V supply capped at 120 kW demand; peak shaving via smart scheduling is mandatory. |
| How many docking lanes are required? | Provide at least 24 active docking ports plus four buffer bays for packs under diagnostics. |
| How long can a rider wait for a charged pack? | Target median wait ≤3 minutes; 95th percentile ≤6 minutes during peak hours. |
| Which emergency stops are mandated? | Provide at least two illuminated E-stop buttons accessible within 8 m of any docking port and integrate with audio/visual evacuation cues. |
| What safety interlocks are mandatory? | Dual-channel latch verification, contactor isolation before release, and arc-fault detection within 50 ms. |
| How should thermal events be managed? | Automatic isolation, localized aerosol suppression, alarm beacon, and alert to remote operations within 10 seconds. |
| What remote operations support is required? | Provide real-time dashboard feeds, fault escalation within 2 minutes, and manual override tools for the control centre. |
| What maintenance strategy is expected? | Hot-swappable modules with 30-minute mean time to repair and predictive alerts from onboard diagnostics. |
| How will spare packs and parts be managed? | Provide secure storage for 20 reserve packs and critical spares; inventory levels must sync with the client’s ERP nightly. |
| What lighting and signage must the rack include? | Provide Vietnamese-language instructions, LED lighting suitable for District 1 streetscapes, and maintain brightness limits per HCMC regulations. |
| How should the system handle wet-season flooding? | Ensure equipment is elevated above typical flood levels, include drainage channels, and design for safe operation during monsoonal rains. |
| What cultural expectations apply to customer service? | Display courteous messaging in Vietnamese, provide audio prompts, and design the interface to respect local etiquette (e.g., privacy when handling payments). |
| What data privacy requirements are expected? | Store rider data on servers located in Vietnam, comply with local data protection laws, and provide opt-in consent for marketing communications. |
| Are there partnerships with local vendors or authorities? | Coordinate with Ho Chi Minh City Department of Transport and nearby retailers to secure permits, utility access, and shared security measures. |
| How will the system expand in future? | Allow daisy-chaining of up to four racks via standardized power/data bus without disrupting operations. |
| Are there sustainability targets? | Track energy consumption per swap, enable optional solar canopy integration, and report CO₂-equivalent savings monthly. |
| What acoustic limits apply? | Mechanical operations must remain below 55 dB(A) at 2 m during swaps to respect residential noise bylaws. |
| How is vandalism or theft to be handled? | Install tamper sensors, provide CCTV integration points, and trigger automatic lockout with remote notification on breach. |
| What regulatory approvals are anticipated? | Design to meet TCVN electrical safety standards, local fire codes, and municipal public-space licensing requirements. |
| What is the pilot rollout timeline? | Commission prototype rack by Week 10, complete site acceptance by Week 12, and gather user feedback for a Week 14 executive review. |
| Are there expectations for rider growth? | System must scale to 1,500 active riders in six months, supporting 15% month-on-month growth without major hardware changes. |
| How will community engagement be supported? | Provide data for city mobility dashboards and host quarterly workshops with local authorities and rider advocacy groups. |
| What KPIs will determine pilot success? | Swap throughput, rider satisfaction ≥4.5/5, pack incident rate <0.1%, and energy cost per swap within client targets. |
3. Timeline
Organise your work alongside the Week 1–5 teaching sequence:
- Week 1 – Context: confirm site assumption and record a list of stakeholders.
- Week 2 – Needs: write about stakeholder needs, produce context diagrams, and gather regulatory/WHS references.
- Week 3 – Requirements: transform needs into user and system requirements, start the traceability matrix, and outline Concept of Operations use cases.
- Week 4 – Architecture: finalise functional hierarchy and functional flow block diagram, compare at least two rack concepts, and draft the integration plan.
- Week 5 – Synthesis: integrate diagrams, quality-check requirements coverage, complete the reflection, and check the submission before upload.
4. Submission Instructions and Feedback
- Upload the report as a single PDF (11 pt font, 1.15 line spacing, numbered headings, captioned figures/tables).
- Keep the report length within 2,500–3,000 words (±10%) excluding cover page, references, and appendices.
- Reference sources using Harvard or IEEE style, citing course materials, Vietnamese standards, industry reports, and interviews.
- Name the file
StudentID_Assessment1_BatterySwap.pdfand upload via the Canvas Assessment 1 link by the Week 5 deadline (late penalties apply). - Feedback will be released in Canvas within 10 working days, highlighting strengths, improvement areas, and priorities for group assessments.
Individual-to-Group Handover (compulsory)
For Assessment 2 you will be working in a group. Before you join your Assessment 2 group, compile a concise handover pack (one page plus up to two supporting diagrams) containing:
- Snapshot of key stakeholder needs, top user/system requirements, and major risks/assumptions.
- One diagram (context diagram, Concept of Operations sketch, or functional hierarchy) with traceability IDs.
- Write a bullet list of open questions or missing information you recommend the team address early.
Include this as an appendix to your report (combined PDF) and bring it to the first group meeting so teams can quickly understand the work you have done to date.
5. Assessment Criteria
| Component | Criteria | Weight | CLO Alignment |
|---|---|---|---|
| Stakeholder analysis, problem framing, and scenario understanding | Depth of analysis, clarity in framing the problem, articulation of objectives. | 15% | CLO1, CLO3 |
| Concept of operations and scenario workflows | Quality of workflow narratives, diagrams, and safety/operational concepts. | 15% | CLO1, CLO3 |
| Requirements development and traceability | Rigor of user/system requirements, completeness of traceability matrix, preliminary verification. | 25% | CLO2, CLO4 |
| Functional design and architecture justification | Strength of decomposition, functional flow block diagram, trade study, and interface descriptions. | 25% | CLO1, CLO2, CLO3 |
| Integration planning and professional communication | Lifecycle planning, model based system engineering approach, clarity, referencing, and presentation quality. | 20% | CLO1, CLO4 |
6. Academic Integrity
This is an individual assessment. All modelling artefacts, requirements, analyses, and trade studies must be your own work. You may discuss ideas with peers, but shared content cannot be copied directly. Declare any use of digital or AI tools in line with university policy. Academic integrity breaches will be handled under RMIT procedures.