Managing System Design Process Using Axiomatic Design: A Case on KAIST Mobile Harbor Project
Bibliographic record
Abstract
As world-wide container volume increases and very large container ships emerge as a dominant player in the maritime cargo transport market, functional capabilities of container ports need to be greatly enhanced. To address this problem, KAIST is undertaking a project to design a novel container transport system, namely Mobile Harbor. Mobile Harbor refers to a system that can go out to a large container ship anchoring in the open sea, load and unload containers between the container ship and the Mobile Harbor, and transport them to their destinations. Designing Mobile Harbor presents a number of challenges as with many other large-scale engineering projects, especially at the beginning stage of the project. The challenges include diverse system mission scenarios that bring a wide range of different functional needs and constraints, large solution space with rather ambiguous concept selection criteria, difficulty in communicating ideas and concepts among many project participants with diverse background, and constant budget and time pressure, to name a few. For this kind of large, complex projects, the ability to effectively manage system design issues plays an essential role in determining the quality of outcomes of such projects. Properly defining and disseminating Functional Requirements, clarifying interface requirements between its subsystems, and identifying potential conflict, i.e. functional coupling, at the earliest stage of design as much as possible are all part of what need to be managed in a system design project. In this paper, we discuss the KAIST Mobile Harbor project to describe challenges and issues of system design, and illustrate how Axiomatic Design process can facilitate design tasks for a large, complex system.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.021 | 0.017 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.002 | 0.002 |
| Science and technology studies | 0.007 | 0.007 |
| Scholarly communication | 0.007 | 0.005 |
| Open science | 0.003 | 0.005 |
| Research integrity | 0.004 | 0.004 |
| Insufficient payload (model declined to judge) | 0.004 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".