Archives: Assignments

1. Select the capstone use case and name one primary beneficiary, buyer/operator, public authority, technical integrator, and affected non-customer group.
2. For each, record a desired outcome, a concern, a decision they control and evidence they can contribute.
3. Create one feature → capability → performance → service-outcome chain. Mark every assumption.
4. Choose three adoption barriers and turn each into a technical, operational or governance requirement.
5. Define a pilot: baseline, participants, route/context, metrics, data rules and a scale/no-scale decision gate.

DELIVERABLE  One-page stakeholder/value canvas and a half-page pilot gate. These become the adoption section of the capstone.

TEACHING ILLUSTRATION  Scenario: a shared electric shuttle approaches a rough downhill bend. The fleet map suggests reduced grip after rain, but the observation is 40 minutes old. A front-corner damper reports intermittent degradation. This scenario is fictional.

 

1. Define the desired vehicle-level behaviour before, during and after the bend.
2. Separate fast on-board inputs from remote/context inputs. Assign an age and confidence check to each remote item.
3. Choose actuators for path tracking, speed control and ride; name at least three hard constraints.
4. Describe nominal allocation and the degraded strategy if damper force or connectivity becomes unavailable.
5. Select a predictive or learned function and justify why it adds value over a rule baseline.
6. Design one MiL, one HiL and one physical test, with metric, baseline and pass criterion.

DELIVERABLE  One-page control hierarchy and test matrix. It becomes the control-and-safety section of the capstone.

TEACHING ILLUSTRATION  Scenario: an eight-seat accessible shuttle begins service at 06:30 after overnight charging. Ambient temperature is −5 °C, two riders need additional warmth, the first route lasts 70 minutes and the operator requires a defined arrival reserve. The numbers are fictional and must not be presented as project test data.

 

1. Draw the thermal boundaries: cabin zones, occupants, battery, e-drive, ambient environment and charging connection.
2. Define three hard constraints, three optimisation objectives and two user preferences.
3. Choose a preconditioning trigger and the minimum data required. State who controls or consents to each data item.
4. Describe the baseline controller and the bounded decision that an optimisation or RL layer may improve.
5. Propose four evaluation scenarios, including one sensor fault or schedule change.
6. Write one comfort metric, one energy metric, one protection metric and one equity/accessibility check.

Return to the need statement from Module 1. Select one technical claim; for example ride comfort on rough roads, stopping stability on a low-friction split surface, thermal preconditioning energy or a virtual grip estimate.

1. Write the decision that the model must support and the person who will use the result.
2. List the inputs, outputs, states and constraints that must be represented.
3. Choose an initial model level and state two deliberate simplifications.
4. Propose a MiL-to-physical-test sequence. At each stage, name the real artefact introduced and the risk reduced.
5. Write one validation metric, reference measurement, operating envelope and pass threshold.
6. State what the evidence would not allow you to claim.

Choose one context: accessible neighbourhood shuttle, shared taxi, public-transport feeder, last-mile delivery vehicle, municipal service vehicle, or another urban EV approved by your facilitator.

1. Describe the user or operator and the route context in two sentences.
2. List three observed or plausible pain points. Mark whether each is supported by local evidence or still an assumption.
3. Select one SmartCorners asset family that might help. Explain the causal link without promising an outcome.
4. Write two measurable service requirements: one primary benefit and one ‘do no harm’ constraint.
5. Name two stakeholders who must validate the need and one dataset that would reduce uncertainty.

Self-check criterion	Strong response
Specificity	Names a user, service, location/conditions and operational problem
Evidence literacy	Separates known facts, stakeholder claims and assumptions
Causal logic	Links a capability to a measurable outcome through an explicit mechanism
Trade-off awareness	Includes at least one safety, cost, energy, maintenance or equity constraint

Develop a concise, actionable roadmap for piloting and scaling a shared mobility service in your local context, applying the frameworks, tools, and insights from the GEMINI Academy: Shared Mobility in Action course.

Participants will design a Pilot-to-Scale Roadmap tailored to their own city, region, or organization. This roadmap should demonstrate how shared mobility concepts learned in the course can be adapted to local realities (policy environments, mobility needs, and stakeholder ecosystems). See detailed description of the assignment in the attached file.