Managing System Design Process Using Axiomatic Design: A Case on KAIST Mobile Harbor Project
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
<div class="section abstract"><div class="htmlview paragraph">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.</div></div>
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.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
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 it