시스템 공학 무역 연구

매니저 가이드.
Manager 's Guide에는 리더십 및 시스템 엔지니어링에 관한 블로그 게시물이 포함되어 있습니다. 리더십 지위는 관리자와 자신을 관리하기를 원하는 노동자를위한 리더십에 대한 자율 학습 과정을 제공합니다. 이 기사는 사람들에게 동기를 부여하고 프로세스를 개선하는 데 초점을 맞 춥니 다. 사람과 프로세스는 모든 유형의 조직에 공통적이므로 모든 조직에 적용됩니다. 이전 게시물은 시스템 엔지니어링을 다루며 아카이브 또는 핵심 단어를 검색하여 찾을 수 있습니다.
2011 년 6 월 9 일 목요일.
무역 연구 방법론.
3 개의 코멘트 :
이 주제가 귀하의 profesuallyional 영역과 관련이 있습니까, 아니면 취미와 자유 시간에 관한 것입니까?
안녕하세요, 저는 제 웹 로그를 방문한 것을보고 원하는 것을 돌려주었습니다.
. 사이트를 개선하기 위해 문제를 찾는 데 노력하고 있습니다! 일부 개념을 사용하는 것이 적절하다고 생각합니다 !!

무역 연구.
트레이드 오프 (trade-off) 분석이라고도하는 트레이드 스터디는 경쟁하는 대안간에 결정을 내리는 방법입니다. 비공식 무역 연구는 정신적 대안을 단순히 계량하고 결정을 내림으로써 빈번하게 수행되지만 공식적인 무역 연구는 사고를 단련하고 굳건히하고 결정에서 편견을 제거하는 데 도움이됩니다. 무역 연구는 의사 결정시 고려해야 할 여러 가지 기준이있을 때 가장 유용합니다. 각 기준은 서로 다른 중요도를 갖고 있습니다. 예를 들어, 자동차를 선택하면 안전성, 연비 및 비용을 중요하게 생각할 수 있지만 각 요소의 중요성은 동일하지 않을 수 있습니다.
무역 연구는 시스템 공학에서 중요한 도구이지만 광범위한 상황에서 의사 결정을 내릴 때 사용할 수 있으므로 시스템 엔지니어링의 좁은 맥락에서 유용합니다. 공식 무역 연구의 주요 단계는 다음과 같습니다.
대안 식별 기준 선택 기준 가중치 할당 성능 평가 결과 계산.
이 사이트에는 무역 연구를 수행하는 과정을 자동화하는 데 도움이되는 무역 학습 도구가 있습니다. 이 도구를 사용하여 토론을 진행하는 것이 도움이 될 수 있습니다.
대안을 확인하십시오.
모든 무역 연구의 첫 번째 단계는 고려중인 대안을 확인하는 것입니다. 예를 들어, Toyota Camry, Ford Explorer, Ford F150, Porche Boxter 등 여러 가지 잠재적 인 차량 사이를 결정해야 할 수 있습니다. 이 차량들 각각은 고유 한 장점을 가지고 있으며, 무역 연구의 결과는 당신에게 가장 중요한 차량의 속성과 각 차량이 그 속성들을 어떻게 만족시키는지를 기반으로합니다.
기준을 선택하십시오.
대안을 확인한 후, 다음 단계는 결정을 내릴 때 사용될 기준을 선택하는 것입니다. 기준은 이상적인 대안이 가져야 만하는 중요한 속성을 정의합니다. 예를 들어 자녀를 축구 연습에 데려다 줄 가족 차량을 찾고 있다면 자녀가 안전하고 축구 팀 동료들에게 맞는 충분한 공간이 필요합니다. 그러나 주말에 경주를 끌기위한 무언가를 찾고 있다면 속도와 핸들링이 더 중요 할 것입니다.
기준은 모든 결정에 대해 고유 할 것이지만 대부분의 무역 연구에 포함 된 공통 기준은 다음과 같습니다.
기준을 선택할 때, 기준 목록이 완전해야합니다 (즉, 목록은 결정에 영향을 미치는 모든 중요한 속성을 설명합니다). 고유해야합니다 (예 : 기준이 서로 다른 하나의 기준에서 우물은 또 다른 기준에서 잘 수행된다는 것을 의미하고, 그 반대도 마찬가지입니다.)
기준 가중치 지정.
기준의 전체 목록이 결정되면 각 기준의 중요도에 따라 각 기준의 가중치가 할당됩니다. 가중치는 critiera가 전반적인 점수에 얼마나 기여 하는지를 결정합니다. 가중 인자를 결정하기위한 몇 가지 공통적 인 방법이 아래에서 가장 간단한 순서대로 설명됩니다.
선형 가중치.
지금까지 가중치를 계산하는 가장 간단한 방법은 선형 가중치를 사용하는 것입니다. 이 방법에서는 중요도 값이 각 critiera에 일정 규모로 할당됩니다. 예를 들어, 1에서 9까지의 척도가 있습니다. 여기서 1은 가장 중요하지 않으며 9는 가장 중요합니다. 중요도 값이 할당 된 후에는 값이 1로 합쳐 지도록 정규화되어 이러한 정규화 된 값이 가중치 요소가됩니다.
쌍으로 가중치 부여.
pairwise 가중 방법은 기준이 행렬의 행과 열을 따라 배치되는 정사각형 행렬을 작성하는 것으로 구성됩니다. 매트릭스의 값은 기준 쌍 간의 상대적인 중요성을 기반으로합니다. 값은 다음 표에 설명 된대로 1-9 범위에서 선택됩니다.
값은 각 행의 기준을 열의 기준과 비교하고 기준 간의 상대적 중요성을 판별하여 행렬에 입력됩니다. 패밀리 카를 선택한 경우의 행렬 예가 아래에 나와 있습니다. 이 예에서는 안전과 신뢰성이 가장 중요한 기준입니다. 이것은 안전성 및 신뢰성을위한 행을 찾아 내고 이러한 기준 값이 항상 1보다 크거나 같음을 알면 알 수 있습니다. 예를 들어 안전은 편안함보다 중요하며 (3) 연비보다 훨씬 중요합니다 (6). 편안함을 위해 행을 보면 안정성과 비교할 때 값이 1/3이라는 것을 알 수 있습니다. 이는 일관성이 있습니다. 마찬가지로, 연비의 줄에서 안전과 비교했을 때의 가치는 1/6입니다.
한 쌍의 행렬이 구성되면 가중치를 계산할 수 있습니다. 계산은 행렬의 각 행에 대한 기하 평균을 찾아 기하 평균 값을 정규화하여 수행됩니다. 기하 평균은 다음과 같이 계산됩니다.
$$ GM = \ left (N_1 * N_2 *. * N_N \ right) ^ $$
아래 표는 각 행에 대한 기하 평균값과 최종 정규화 된 가중 계수와 함께 매트릭스를 보여줍니다.
분석 계층 구조 프로세스.
AHP (Analytic Hierarchy Process)는 이전 섹션에서 설명한대로 pairwise 행렬을 구성하여 시작합니다. 그러나 각 행에 대한 기하 평균을 계산하여 가중치를 결정하는 대신 행렬에 자체를 곱한 다음 결과 행렬의 각 행을 합하고 정규화합니다. 행렬 곱셈은 정규화 된 값이 수렴 할 때까지 수행됩니다. 이 과정에서 각 곱셈의 결과 행렬은 다음 반복을 위해 자체 곱해진다. 수렴을 테스트 할 수 있지만 일반적으로 곱하기를 3 번 ​​수행하는 것이 안전합니다. 최종 행렬에 도달하면 행렬의 행을 합하여 값 열을 얻습니다. 합계 된 행 값의이 열은 최종 가중치를 제공하기 위해 정규화됩니다.
AHP로 인해 발생하는 가중치는 전형적으로 pairwise 방식의 가중치와 매우 유사합니다. 예를 들어, 아래 표의 가중치는 이전 섹션과 동일한 pairwise 행렬을 사용하는 AHP 방법으로 계산되었습니다.
우리는 구조 계산기를 선택할 수 있습니다. 다음은 몇 가지 예입니다.
성과를 평가하십시오.
기준을 선택한 후에 대안의 성과 값을 평가합니다. 등급은 대안이 기준을 얼마나 잘 충족시키는지를 기준으로합니다. 모든 경우에 등급 값이 각 기준에 지정되고 값이 표준화됩니다.
이전 섹션의 기준을 사용하여 가족 용 자동차를 구매 한 경우에 대한 몇 가지 예가 시연됩니다.
질적 인 성과.
안전과 같은 기준의 경우, 수치가 알려지지 않을 수도 있으며 대신 각 대안이 얼마나 잘 수행되는지에 대한 일반적인 질적 인 느낌 만이 알려져 있습니다. 이 경우 평가 값은 1-5의 척도에 따라 대안에 할당 될 수 있습니다. 1은 매우 열악하고 5는 우수합니다.
몇 가지 차량의 성능 등급에 대한 예가 아래 표에 나와 있으며, 이 값은 1-5의 척도로 정 성적 등급을 기준으로합니다. 그런 다음 값을 정규화하여 최종 성과 점수를 얻습니다.
양적 성능 - 최고의 가치.
매우 일반적으로 수치는 성능으로 알려져 있고, 높은 수치는 낮은 수치보다 낫습니다. 이 경우 실제 성능 값을 직접 사용할 수 있으며 값을 정규화하여 최종 성능 점수를 얻을 수 있습니다. 승객 수용량의 예가 아래에 나와 있으며, 이 값은 단순히 승객의 수입니다.
정량적 성능 - 낮은 가치 최상의.
숫자 값이 성능에 알려져 있지만 높은 값 대신 낮은 값이 가장 좋은 경우 성능 값이 기록되고 중간 역전 값은 다음을 기준으로 계산됩니다.
반전 된 값의 경우 실제 값은 실제 값이 최소값보다 큰 값이기 때문에 실제 값은 최대 값 아래의 동일한 거리입니다. 그런 다음 반전 된 값을 정규화하여 최종 성과 점수를 얻습니다.
차량 비용의 예는 다음과 같습니다.
결과 계산.
결과를 계산하기 위해 테이블이 아래와 같이 구성됩니다. 기준은 각 기준에 대한 가중치 계수와 함께 행 아래에 나열되며 대안은 열 전체에 나열됩니다. 성과 점수는 각 기준과 관련하여 각 대안에 대해 열거됩니다. 그런 다음 성능 점수에 해당 기준의 가중치를 곱하여 가중 점수를 계산합니다. 그런 다음 가중 점수를 각 대안에 대해 합계하고 합산 가중 점수를 스케일링하여 최종 점수를 계산하여 가장 높은 점수를 얻는 대안이 100 점을 얻도록합니다.
결과 해석.
무역 연구는 객관식만큼 객관적입니다. 기준에 대한 가중치를 설정하거나 대안의 실적을 평가할 때 귀하가 가진 모든 편향이 결과에 반영되므로 무역 연구 결과를 절대적으로 받아 들여서는 안됩니다. 결과에 편향의 위험을 최소화하기 위해 기준 가중치 및 성능 값을 수정하여 결과가 이러한 요인에 얼마나 민감한지를 확인하는 민감도 조사를 수행해야합니다.
메일 링리스트.
최신 개선 사항에 대한 업데이트를 구독하십시오.

시스템 엔지니어링 연구
국방 취득이 쉬워졌습니다.
홈 취득 주제 취득 지수 획득 프로세스 요구 사항 프로세스 자금 조달 프로세스 경력 색인 계약 닫기 & # 038; 법률 재무 관리 정보 기술 물류 & # 038; 공급 생산 & # 038; 품질 프로그램 관리 소프트웨어 관리 시스템 엔지니어링 테스트 & # 038; 평가 닫기 작업 색인 비용 계산 DoDAF 산출물 가치 관리 인텔리전스 & # 038; 보안 제안 개발 요구 사항 개발 위험 & # 038; 안전 관리 일정 개발 기술 개발 사업 & # 038; 마케팅 닫기 모든 주제 닫기 참조 Main References Guides & # 038; 핸드북 마일스톤 매트릭스 템플릿 닫기 검색 내 페이지 가입하기.
회원 메뉴 멤버 홈 취득 뉴스 도구 / 리소스 커리어 에디션 (Coming Soon) Training Center Adv. 리소스 직업 집중 조명 작업 연결 비즈니스 버전 (출시 예정) 기회 인텔 센터 ​​Gov 고객 예산 정보.
시스템 공학.
무역 연구는 자격을 갖춘 솔루션 목록 중에서 선호하는 솔루션을 식별하는 연구입니다. 무역 연구는 다음과 같은 기준에 따라 이러한 해결책을 검토 할 것입니다. 비용, 일정, 성능, 중량, 시스템 구성, 복잡성, 상업용 기성품 (COTS) 사용 등이 포함됩니다. 무역 연구는 시스템 디자인을 통해 개념 개발에서 획득 프로그램을 통해 수행됩니다. 시스템 엔지니어링에서 주로 운영 및 시스템 수준 요구 사항을 결정하는 데 사용됩니다.
무역 연구는 프로그램의 수명주기 전반에 걸친 의사 결정을 지원하기 위해 사용됩니다. 무역 연구는 운영 능력, 기능 및 성능 요구 사항, 설계 대안 및 관련 제조, 테스트 및 지원 프로세스 중에서 수행됩니다. 프로그램 일정; 대안을 체계적으로 검토하기위한 수명주기 비용. 일단 대안이 확인되면, 무역 연구팀은 대안을 분석하기 위해 일련의 결정 기준을 적용합니다. 이러한 기준은 & # 8216; 어느 대안이 최적이며 권장 될지 결정하십시오.
대부분의 무역 연구는 엄격하게 공식적 또는 비공식적 인 연구가 아닙니다. 보통 그들은이 두 극단 사이 어딘가에 빠져 있습니다. 일반적으로 고 부가가치, 고위험 또는 기타 영향력있는 결정에 대해서는 공식 무역 연구가 필요합니다. 모든 무역 연구가 정식 과정의 엄격함을 따라야하는 것은 아니지만 다음과 같은 프로그램의 특정 상황에 맞게 조정되어야합니다 : [1]
프로그램 위험의 가능성 또는 심각성, 사용 된 객관성 및 양적 데이터, 사용 가능한 데이터의 세부 사항, 무역 연구를 수행하는 데 필요한 시간, 노력 및 자금.
무역 연구는 다음 활동을 지원합니다 :
면책 조항 : AcqNotes는 국방부 (Department of Defense), 공군, 해군 또는 육군 웹 사이트가 아닙니다. 이 웹 사이트에 포함 된 모든 정보, 제품, 서비스 또는 하이퍼 링크는 국방부, 공군, 해군 또는 육군의 승인을 구성하지 않습니다. 스폰서의 연방 정부 추천을 의도하지 않았습니다. 이 웹 사이트에 포함 된 정보는 정보 제공의 목적으로 만 사용되었으며 방향이나 조언의 형태로 의도 된 것이 아니며 특정 문제와 관련하여 완전한 결정적인 진술로 신뢰해서는 안됩니다. 이 웹 사이트 정보에 대한 액세스 및 사용은 사용자의 위험 부담입니다.

4 장 : 시스템 엔지니어링 도구.
David Beale과 Joseph Bonometti.
이 장은 학생 팀이 SE 설계 과정에서 필요할 수있는 시스템 엔지니어링 도구의 보완 사례를 제공하기위한 것입니다. 확실히 업계에서 사용 가능한 도구의 다양성과 정교성을 모두 포함하지는 않습니다. 여기서 제시되는 것은 핵심 프로젝트이며, 학생 프로젝트에 쉽게 적용 할 수있는 기본 도구와 단순 도구가 있습니다.
아티스트의 "도구"에 비해 시스템 공학의 아이디어를 강화하는 것이 좋습니다. 모든 직업에서 모든 도구 세트의 연습, 이해, 유지 관리 및 재봉이 필요하지만 도구가 예술의 목표가되거나 최종 목표 인 경우에는 마스터가 실패합니다. 오늘날 기술적이고 고도로 복잡한 우주 항공 분야에서 위험은 고객의 눈에 성공적인 제품을 생산하기위한 SE 도구의 과다 사용과 의존입니다. 건전한 엔지니어링과 훌륭한 판단 만이 그 점에서 승리 할 것이며, "프로세스"의 의존은 시스템 엔지니어의 노예가되고 문서 작성, 마감일 지정, 예산을 충당하고 무의미한 데이터를 제시한다. 따라서 다음과 같은 목적으로 도구를 적용하십시오.
의사 소통을 돕습니다 "멍청한"오류를 방지하십시오 가장 중요한 문제 또는 문제를 강조하십시오 시간을 초월하십시오 주어진 상황에 맞는 최상의 제품을 만드십시오.
도구를 다음과 같이 취급하지 마십시오.
프로젝트에서 가장 중요한 것 좋은 엔지니어링 또는 건전한 판단을위한 대체 모든 (특히 설계) 오류를 제거하는 프로세스 생산을 위해 지급 (또는 채점) 한 것.
개요 형식으로 문서화하십시오.
제품 고장 구조 (PBS),
운영 개념입니다.
검증 및 검증.
인터페이스 제어 문서.
질량, 전력, 비용, 링크 예산.
고장 모드 분석.
스토어 및 기준선 문서.
작업 분류 체계 (WBS), 간트 차트, SEMP.
표 1. 시스템 엔지니어링 도구. * 기타 도구는 건축 설계에는 적용 가능하지만 기능 분석이나 기능 분해 (2 장의 예 참조), 의사 결정 행렬, House of Quality, 소프트웨어 시뮬레이션 (8 장의 예 참조) 이외에이 장에서는 제시되지 않았지만, 프로토 타이핑 및 모델링.
제품 고장 구조 (PBS)
제품 분석 구조 (PBS)는 프로젝트의 하드웨어 및 소프트웨어 제품을 계층 적으로 분석 한 것입니다. 이것은 SE 아키텍처 설계 기능의 일부로 작성됩니다. 다음 예 (그림 1)는 (NASA, 2007)에서 발췌 한 것입니다. 이러한 삽입은 PowerPoint의 삽입 & gt; 다이어그램 & gt; 조직도. 일부 재량권을 사용하여 블록을 결합하거나 (주로 소규모 프로젝트의 경우) 다른 사람들에게 구체성을 부여 할 수 있습니다. PBS는 작업 영역을 전달하고 작업 배정, 예산 책정 및 기타 SE 도구 개발을 지원합니다. SOFIA 프로젝트 (그림 2)의 경우, 두 개의 주요 하위 시스템은 관측 시스템 (Observatory System)과 지상 시스템 (Ground System)입니다.
그림 1. 발사체 용 NASA 제품 고장 구조 (PBS).
그림 2. SOFIA 적외선 망원경의 PBS 예제.
작업 분류 체계 (WBS)
그림 3은 그림 2의 SOFIA 예제 시스템에 대한 WBS (하드웨어, 소프트웨어, 서비스 및 데이터의 계층 적 분할)를 보여줍니다. WBS는 최종 목적을 달성하기위한 세분화 된 노력의 트리이며 모든 작업 기능. PBS에없는 WBS의 추가 작업 기능에는 프로젝트 관리, 시스템 엔지니어링 등이 포함됩니다 (NASA, 1995). 또한 WBS는 비용 견적, 인력 요구 사항 등을 추가합니다. 이 문서는 모든 SE 도구와 마찬가지로 프로젝트에 맞게 조정됩니다. 그것은 다음 리뷰 또는 브리핑에 포함시킬 단순히 "마지막 프로젝트의 패키지"의 복사본이 아니라 작업에 유용하고 적용 가능해야합니다. 모든 SE 도구와 함께 사용하는 좋은 규칙 : 프로젝트를 지원할 기능이 없으면 사용하지 않아야합니다. 소규모 학생 프로젝트의 경우 학습 목표는 의심스런 프로세스 도구를 포함시키고 추적을 매우 중요하게 만듭니다. 또한 한 클래스 또는 여러 학생 그룹에서 다른 학생 그룹으로 전달되는 학생 프로젝트는 구성 관리를 통해 명확한 문서화가 필요합니다.
그림 3. SOFIA Project의 최상위 WBS 및 Observatory System WBS의 세부 정보
WBS에는 PBS와 동일한 요소가 많이 있지만 관리, 안전성, 안정성 또는 기타 중요한 감독 활동이 추가됩니다. "사람들"파생 된 구성 요소로 간주 될 수있는 반면 PBS는 프로젝트를 구성하는 "사물"입니다. 다시 말하지만, 목적은 프로젝트의 복잡성과 성격을 전달하고, 설계 및 엔지니어링 프로세스를 자극하고 분명한 누락이나 중복을 방지하는 것입니다.
이 다음 WBS는 비정상 또는 고급 시스템 엔지니어링 작업을 위해 기존 WBS를 설정하는 방법의 예입니다. Momentum Exchange Electrodynamic Reboost (MXER) 시스템은 위성을 집어 GEO, 달 또는 행성 간 공간으로 궤도에 올릴 수있는 100km 공간 테더입니다. 지구의 자기장을 밀어 올려서 다시 부스트되며 LEO에 착수 된 다음 위성에 힘을 부여 할 준비를 할 수 있습니다. WBS에서 고유 한 구성 요소와 요구 사항을 파악하는 방법에 유의하십시오. "Propagator Code"는 밧줄 끝이 랑데부에있을 곳을 예측하는 별도의 컴퓨터 알고리즘입니다. 이것이 설계, 제어 및 운영의 핵심 요소 였기 때문에 작업 할 최상위 영역이었습니다. 전통적인 항공 전자 공학이나 우주선 통제 구역에서 하위 계층 항목으로 포함될 수 있었지만, 이 기술 개발 프로젝트에서는 최상위에 배치하는 것이 가장 좋았습니다. 어떻게하면 알 수 있습니까? 그것은 시스템 공학의 기술입니다! 경험, 엔지니어링 직관력 및 설계 팀원과의 협의가 그러한 판단을 내리는 전형적인 방법입니다. "잘라내어 붙여 넣기"하고 다음 SE 도구로 넘어 가기 쉽기 때문에 마지막 프로젝트의 문서를 기반으로해서는 안됩니다.
그림 4. MXER (모멘텀 Exchange Electrodynamic Reboost) 테더 작업 분류 체계.
WBS는 계층 적 차트 일 필요는 없습니다. Gantt 차트와 MS-Project를 사용하는 WBS 개요 구조를 기반으로하는 WBS 예제 2 장을 참조하십시오.
무역 연구.
무역 연구는 문제에 대한 해결책을 선택하거나 특정 프로젝트의 개발 영역을 제한하는 데 사용되는 도구입니다. 제품 개발주기 초기에 자주 사용되며 제품을 올바르게 사용하면 제품 수명주기에서 가장 중요한 엔지니어링 작업 중 하나가 될 수 있습니다. 고도로 정교한 프로젝트 또는 "시스템 시스템 (systems-of-systems)"설계에서 무역 연구는 종종 매우 복잡하며 엔지니어링 세부 사항이 일부 영역의 실제 설계 프로세스에 접근합니다. 이 연구는 또한 어떤 요소가 진정으로 성공에 가장 영향력있는 요소인지를 정의하고 밝히는 데 매우 중요합니다. 가장 놀라운 결과는 초기 (A 단계 또는 B 단계) 무역 연구에서 기인해야하며 그렇지 않은 경우 변화가 필요한 시간과 비용이 과도한 프로젝트가 끝날 때 놀라움이 올 것입니다.
문제에 여러 솔루션이있는 경우 무역 연구는 각 솔루션에 숫자 값을 제공하여 솔루션을 순위를 매 깁니다. 간단한 방법은 각 옵션에 대한 숫자 값을 결정하는 것입니다. 이는 종종 평가 기준에 대한 가중치 및 정규화 척도를 기반으로 수행됩니다. 평가 기준은 우리가 무역 연구에 포함시키고 자하는 중요한 요소입니다. 가중치 요소는 평가 기준이 서로 상대적으로 얼마나 중요한지를 결정하는 데 사용됩니다. 정규화 척도는 각 평가 기준에 대해 숫자 값을 설정할 수있는 일정한 간격 눈금을 만듭니다.
비용, 질량, 부피, 전력 소비, 유산 및 사용 편의성은 몇 가지 기본 평가 기준입니다 (프로젝트에 따라 추가 기준을 추가하는 것이 바람직하거나 여기에 나열된 기준을 삭제하는 것이 적절할 수 있음). 또한이 과정에서 가중치 및 표준화 척도의 선택이 매우 중요하다는 것을 이해하는 것이 매우 중요합니다. 결과가 고의적이거나 의도하지 않은 편향에 매우 민감 할 수 있으므로이 값을 설정할 때는 많은주의를 기울여야합니다. 예를 들어, 초기 구매 가격과 함께 자동차를 구입할 때 보험 비용을 평가 기준으로 나열하지만 보험료에 구매비보다 훨씬 큰 가중치를 추가하면 다른 자동차 옵션의 순위 결과가 현저히 다릅니다. 보험료가 구매 가격보다 훨씬 적고 다양한 자동차 사이에서 약간 차이가있을 때, 진정으로 원하는 것이 전체 라이프 사이클 비용이 낮거나 마일 당 최저 비용 인 경우 최상의 결과를 얻을 수 없습니다.
일부 매우 근접한 거래 공간에서, 다양한 옵션 중에서 구별하고, 계량 스케일 (예를 들어, 1, 3 및 9의 가중치 스케일)을 채용 할 수있는 욕망이있을 수있다. 이것은 의도적으로 옵션들 사이의 작은 차이를 부풀려 명확한 "승자"를 결정할 수있게합니다. 이러한 계획은 옵션을 구분할 수없는 경우에만 매우 신중하게 사용해야합니다.
간소화 된 무역 연구 단계.
1. 문제를 정의하십시오.
2. 솔루션에 대한 제약 조건을 정의합니다.
3. 3-5 개의 솔루션을 찾습니다.
4. 평가 기준을 정의하십시오.
5. 가중치를 정의하십시오.
6. 정규화 척도를 정의하십시오.
7. 무역 연구 (예 : 스프레드 시트 형식)
8. 솔루션의 순위를 매 깁니다.
무역 연구 사례 - 자동차 구입 (J-M Wersinger 및 Thor Wilson에서)
위에 나열된 단계를 기반으로 :
1. 나는 새로운 차를위한 최선의 선택이 무엇인지 찾고 싶다.
2. 차는 $ 50,000 이하 여야하며 현지에 있어야합니다.
3. 37,000 마일의 흑인 시민권 자로서 열악한 환경에서 4,000 달러의 비용이 든다. 우수한 상태의 57,000 마일과 17,000 달러의 값이있는 빨간 BMW. 6,000 마일의 흰색 파사 트이며 7,000 달러의 좋은 상태.
4. 비용, 주행 거리, 차의 상태 및 차의 색깔.
5. 자동차의 비용과 상태에 대해 3, 마일리지에 대해 2, 자동차 색상에 대해 1의 가중치를 지정하십시오.
6. 정규화 척도 :
자동차 상태.
차 색깔.
표 2. 무역 연구 사례.
무역 연구 사례 - CubeSat 용 마이크로 컨트롤러 비교 (AUSSP, 2007)
표 3. 무역 연구 사례, 마이크로 컨트롤러 vs. FPGA.
이것은 CubeSat 어플리케이션에서 표준 8 비트 마이크로 컨트롤러와 Antifuse (1 회 프로그래밍 가능) FPGA (Field Programmable Gate Arrays)의 상대적인 강점과 약점을 평가하기 위해 C & DH 하위 팀이 수행 한 무역 연구입니다. 마이크로 컨트롤러는 CubeSat 애플리케이션에서 광범위하게 사용되었지만 FPGA는 태양 동기 저궤도에서 흔히 볼 수있는 방사선 유도 단일 이벤트 업셋 (SEU) 솔루션을 제공 할 수있는 비교적 새로운 기술입니다. 평가 기준은 거래가 각 카테고리의 특정 하드웨어가 아닌 각 카테고리의 하드웨어의 필수 특성을 비교할 수 있도록 선정되었습니다.
결과 : CubeSat에 구현 된 하드웨어의 고유 방사선 내성은 매우 중요합니다. Antifuse FPGA는 소형 위성에서 SEU를위한 솔루션 인 것처럼 보였으 나 통상적 인 마이크로 컨트롤러보다 높은 점수를 얻지 못했습니다. 성능, 비용, 시간 및 각 시스템 구현 범위가 비교 될 때 FPGA는 성능 범주 만 취하는 것처럼 보이며 마이크로 컨트롤러는 다른 범주를 스윕합니다. 총 가중 점수의 30 %에서 방사선 내성 (결과의 강건성을 확인하기 위해 분석을 바이어 싱하는 예)이 있더라도 FPGA는 놀랍게도 마이크로 컨트롤러를 추적합니다. 의심의 여지없이, 이러한 유형의 무역 연구는 더 많은 자원, 더 많은 시간, 더 많은 경험이 풍부한 엔지니어를 가진 임무에 대해 매우 다른 결과를 가져올 것입니다. 그러나 올바른 경로는 논리적 SEU 감지 및 수정 알고리즘과 결합 된 표준 마이크로 컨트롤러를 구현하는 것입니다.
이는 표준 프로그래머블 컨트롤러를 더욱 견고하게 만든 다른 서브 시스템에 대한 시스템 엔지니어링의 영향을 고려하지 않은 서브 시스템 비교입니다. 하나의 명령어 집합 만 구현할 수 있기 때문에 모든 제어 서브 시스템의 품질과 신뢰성이 향상 될 것입니다. 이러한 다른 하위 시스템은 기술 결정을 일찍 잠그고 소프트웨어 변경을 통해 문제를 해결할 능력이 적습니다. 시스템 엔지니어링 (또는 프로젝트 관리) 관점에서 볼 때 SEU 수의 증가, 차폐시 추가 질량 또는 구성 요소 레이아웃에서의 노력 (탱크, 구조 등의 차폐 효과를 이용함)은 모두 유연한 방사선은 C & DH 서브 시스템을 강화시킨다.
인터페이스 제어 문서 예제.
Interface Control Documents (ICD)는 본질적으로 단순하기 때문에 서브 시스템 팀간에 기술 사양 및 요구 사항을 잘못 전달하는 것이 쉽고 (과거의 경험이 입증 된) 모든 장소를 기록합니다. 잘못 조립 된 볼트 구멍이나 누락 된 커넥터 핀은 최종 조립이 완료되고 프로젝트가 정해진 발사 일을 맞춰 일정보다 몇 주 늦은 경우 수정하는 데 비용이 많이 든다. 이 문서는 표준 및 높은 수준의 요구 사항을 준수하기 위해 전압, 유체 유량, 열 부하 등을 다시 확인하는 또 다른 장소입니다. ICD는 또한 실제 작업 어셈블리에 필요한 와이어 링, 브래킷 및 기타 하드웨어의 형태로 계획되지 않은 "누락 된 질량"을 설명하는데 도움을 줄 수 있습니다. 모든 시스템 구성 요소가 종단마다 연결되는 경우는 드물기 때문입니다.
ICD는 문서 일뿐 아니라 개발 과정에서 실제 구성 요소를 확인하고 테스트하도록 설계된 하드웨어입니다. 이는 특히 전 세계에서 개발되는 구성 요소와 하위 시스템이있는 대규모 프로젝트에서 유용합니다. 부품을 물리적으로 조립하는 대신, 인터페이스 하드웨어 모델은 그룹의 일정 또는 개발 프로세스에 영향을 미치지 않고 각 부품에서 개별적으로 구성되고 테스트됩니다. ICD는 지상 장비 및 무선 통신에도 적용됩니다. 궁극적으로 상호 연결될 개별 기능을 문서화 할 필요가있는 곳이라면 ICD를 개발할 수 있습니다. 다음 예제에서는 다양한 문서 형식을 보여줍니다. 테이블 또는 스프레드 시트 형식이 일반적이지만 ICD에는 기술 문서, 그림, 하드웨어, 그래프 및 사양 참조가 포함될 수 있습니다.
시스템 엔지니어는 ICD를 최신 상태로 정확하게 유지해야 할 책임이 있습니다. 서브 시스템 리드는 종종 그들이 설계하고 구축하고자하는 사양으로서 마지막으로받은 것을 맹목적으로 적용합니다. 따라서 시스템 엔지니어는 모든 팀이 모든 변경 사항을 업데이트하고 충돌이 설계 단계 초기에 해결되도록해야합니다. 또한 레이아웃 룸, 질량, 열 접촉, 물리적 강성 및 전기 / 데이터 매개 변수가 임무 목표뿐만 아니라 모든 서브 시스템에 대해 만족 스러운지 확인할 필요가 있습니다.
아날로그 신호 이름 (인터 모듈)
3.3V 규정 전원.
CDH MCU ADC (PF0)
5.0V 정격 공급.
CDH MCU ADC (PF1)
TNC 전원, XCVR 전원.
CDH MCU ADC (PF2)
아무것도 직접 사용하지 않습니다.
EPS의 ADC1에서 I2C를 통해.
EPS의 ADC1에서 I2C를 통해.
태양 전지 출력.
EPS의 ADC1에서 I2C를 통해.
전체 배열
EPS의 ADC1에서 I2C를 통해.
아무것도 직접 이걸로부터 구동.
EPS 전류 (전압으로 전송)
배터리 1 충전.
EPS의 ADC3에서 I2C를 통해.
배트 1 방전 전류.
EPS의 ADC3에서 I2C를 통해.
bat2 충전 전류.
EPS의 ADC3에서 I2C를 통해.
배트 방전 전류.
EPS의 ADC3에서 I2C를 통해.
태양 전지 어레이 출력 전류.
ADC1on EPS의 I2C를 통해
5.0V 버스 전류 소모.
EPS의 ADC1에서 I2C를 통해.
3.3V 버스 전류 소모.
EPS의 ADC2에서 I2C를 통해.
3.7V 버스 전류 소모.
EPS의 ADC2에서 I2C를 통해.
태양 전지 1 전류.
EPS의 ADC2에서 I2C를 통해.
태도 결정.
태양 전지 2 전류.
EPS의 ADC2에서 I2C를 통해.
태양 전지 3 전류.
EPS의 ADC2에서 I2C를 통해.
태양 전지 4 전류.
EPS의 ADC2에서 I2C를 통해.
태양 전지 5 전류.
EPS의 ADC2에서 I2C를 통해.
태양 전지 6 전류.
EPS의 ADC2에서 I2C를 통해.
트랜시버 공급 전압.
COM 보드의 ADC에서.
Transcvr 릴레이가 작동하는지 확인하십시오.
모두 동일한 기준 전압이 필요하다.
서미스터를 CDH의 ADC0에 연결하십시오.
일부를 제거해야 할 수도 있습니다.
서미스터를 CDH의 ADC0에 연결하십시오.
서미스터를 CDH의 ADC0에 연결하십시오.
서미스터를 CDH의 ADC0에 연결하십시오.
서미스터를 CDH의 ADC0에 연결하십시오.
서미스터를 CDH의 ADC0에 연결하십시오.
서미스터를 CDH의 ADC0에 연결하십시오.
CDH의 ADC0에 대한 온도 변환기.
서미스터 - MCU (PF7)
2 차 냉방 임시 직원
서미스터 - MCU (PF4)
서미스터 - MCU (PF5)
서미스터 - ADC on (PF6)
표 4. 인터페이스 제어 문서 예제.
표 5. MCU / TNC 인터페이스.
표 6. 인터페이스 제어 문서 예제.
대량 예산 사례.
우주 항공 애플리케이션의 경우 대량 예산 스프레드 시트는 시스템 엔지니어의 도구 상자 아이콘입니다. 질량 최소화는 항공기, 로켓 및 우주선 설계에서 매우 중요하기 때문에 여기에서 최종 결과는 종종 SE에서 가장 많이 모니터링되고 괴롭힘을 초래하는 결과입니다. 대단히 중요하지만, 대량 예산은 설치하고 사용하는 것이 간단합니다. 불행히도, 그것은 종종 잘 예측되지 않고 확실히 남용 된 SE 도구입니다. 질량이 중요하기 때문에 작은 오류라도 우주 항공 분야에서 큰 문제가 될 수 있습니다. 30 %의 마진은 새 시스템이거나 독자적인 기술을 보유한 시스템 또는 서브 시스템에 50 % 이상 추가 된 예비 질량 견적에 일반적으로 추가됩니다. 이전 임무의 사본 인 우주선조차도 각 임무마다 고유 한 환경이 있으며 거의 ​​모든 요구 사항을 수정하면 대량 처벌이 될 것이기 때문에 10 %의 마진을 지니게됩니다. 어떤 것들은 추진체와 같은 평범한 매스 마진으로 가장 부담스럽지 않습니다. 이러한 유체는 무거 우며 궤도 분석 및 기타 요인으로부터 일반적으로 잘 알려져 있습니다. 상당히 방대하지만 본질적으로 "멍청한 질량"인 무거운 방사선 차폐의 경우, 2 % 이하의 여백이 적용될 수 있습니다.
시스템 엔지니어는 서브 시스템이 생산하는 모든 가치를 입력하고 팀에 총액을 발표하는 사무원이나 비서가되어서는 안됩니다. 초기 총 질량을 산출하고, 각 하위 시스템에 최대 질량 허용치를 할당하고, 부품, 구성 요소 또는 시스템 레벨에서 우발 사태에 대한 지침을 제공하는 것에 대한 판단이 있습니다. 합계는 발사체 한도, 계획된 적재물 또는 질량 기준의 비용 목표와 같은 다른 임무 수준 기준을 충족해야합니다. 첨단 기술이 필요한지 또는 대량 추정치를 재 할당할지 결정하는 것은 엔지니어링 통찰력을 필요로합니다. 시스템 엔지니어는 팀에 대한 전반적인 최상의 결정을 내리고 하위 시스템 간의 피할 수없는 갈등을 해결하기 위해 "정직한 중개인"역할을해야합니다.
표 7. C & DH 예산의 예.
전력 예산의 예.
전력 예산은 종종 편의를 위해 서브 시스템 레벨에서 유지되지만, 이는 실제로 시스템 엔지니어의 기능이자 대량 예산만큼의 관심사입니다. 하위 시스템, 기술 선택 및 임무 운영의 통합간에 거래가 이루어집니다. 두 가지 중요한 전력 예산이 있습니다. 총 전력 (모든 것이 켜짐) 및 작동 한계 (최대 전력 허용). 여러 번 전원 예산이 특정 기능을 제한하고 작동 모드를 제한합니다. 데이터 전송은 종종 전력 집약적 인 작업이며 다른 하위 시스템이 종료되거나 유휴 모드 일 때 특정 임무 기간으로 제한됩니다. 지구 궤도에 진입하는 인공위성은 태양 전지 패널이 더 이상 전력을 공급하지 못하는 암흑기를 가지며 중요한 배터리를 가열하기 위해 배터리를 예약해야합니다. 이러한 거래 및 운영 결정은 단일 서브 시스템 리드에 의해 전력 예산이 유지되는 경우에도 SE 수준입니다.
아래의 C & DH 예산 예시에는 몇 가지 전원 모드 또는 상태가 나열되어 있습니다. 각각은 자체적으로 허용되는 상한 또는 하한을 가지며 각각은 개별적으로 계산됩니다. 이러한 상태는 임무 모드와 타임 라인에 해당합니다.
표 8. C & DH 전력 예산의 예.
데이터 및 링크 예산 예제.
전력 예산과 마찬가지로 데이터 및 링크 예산은 종종 시스템 엔지니어 수준에서 전체 조정의 책임하에 서브 시스템 리드에 의해 유지됩니다. 데이터 예산은 통신에 사용할 수있는 시간과 전송 속도에서 파생됩니다. 일반적으로 두 가지 속도와 종종 두 개의 개별 시스템이 있습니다. 하나는 시스템에 대한 업 링크 또는 통신을위한 것이고 다른 하나는 데이터의 다운 링크를위한 것입니다. 고려해야 할 요소가 많으며 이러한 견적을 내릴 때 엔지니어링 판단이 필요합니다. 데이터의 품질, 해상도, 오류 검사, 패키지 크기 및 유사한 기준은 데이터 및 링크 예산의 일반적인 추적 매개 변수입니다.
표 9. C & DH 데이터 예산 예.
표 10. 링크 예산 예제.
고장 모드 분석.
고장 모드 분석은 위험 관리를위한 도구입니다. 위험 관리의보다 엄격한 엔지니어링 또는 기술적 측면입니다. 실패 모드는 무언가가 실패하는 방식입니다. 모든 실패에는 하나 이상의 결과가 있으며이를 장애 영향이라고합니다. 실패 원인은 실패를 유발하는 원인입니다. After identification of all possible failures the effects of the failure are estimated. Next a mitigation plan is prepared for each potential failure cause.
Failure Modes Analysis on the CubeSat.
Because the cubesat project does not have the funds or the available space to mitigate every potential failure, the system must be redundant, fault tolerant, and able to correct detected errors. Failure Modes Analysis is done to determine what the potential failures are in a design and how to mitigate them. This analysis determines the relation between the failure of a single component and its effects on the system as a whole. We accept that no system is perfect, and so some risks are acceptable. Therefore, mitigation attempts will be focused on those failures, which might cause mission failure. In most cases, a secondary component can be used to mitigate any mission failure. The table immediately following shows the four different ways a component failure can affect the whole system.
Table 11. Failure Mode Analysis, Codes of Severity of a Potential Failure.
Identified Single Point Failures.
A single point failure occurs if the mission fails as a result of a single component on the satellite failing. Simply put, it is hardware that the satellite cannot operate without. It is extremely important to detect and eliminate all single point failures that could arise on AS-I. In an effort to eliminate single point failures, a redundancy philosophy has been adopted. The redundancy philosophy states that all satellite hardware identified as single point failure components must have redundant (secondary) hardware. Generally having redundant hardware means simply having two of the same component where they operate independently. A common variation to this theme of “if it fails, use the other one”, is the hot spare where the second component is active and functioning and continually ready to operate at any moment. Sometimes the units are regularly swapped as the primary unit for other reasons, such as to support battery lifetime or prevent joint seizing in mechanisms.
Other redundancy philosophies include having a totally different piece of hardware as the backup. This may be a low gain antenna serving the housekeeping needs and a high gain antenna for the mission science. However, if one fails the other can perform the same duty, but with diminished total data throughput. As with most aerospace related redundancy schemes, this provides a significant mass savings over having two of both types of communications systems onboard. Another mass saving method is to identify the actual weak point in the subsystem and make the redundancy at the component or part level. A good example is in rocket fluid valves where the valve housing is the heaviest and least likely part to fail. In the past, welding in a second complete valve inline or in parallel was the solution. However, since the failure is almost always in the valve seat (e. g., not closing tight), redundancy can be achieved in duplicating the seat seals and in dual electromagnet actuating coils. This not only saves the mass of a valve housing, but also the cost and risk of two more welds in the system. Redundancy also can be in de-rating components to ensure they last the mission lifetime or in adding margin to a subsystem so if it's redundant part fails, it can “ramp up” to higher performance and diminish or eliminate the loss. A spacecraft power conversion box or transformer might operate as two low-power units supplying the primary instrument high voltage, thus gaining long life with lower risk, but each having the capacity to meet the entire voltage requirement (or the minimum for mission success) should the other component fail. Details on the AS-I redundancy choices for the single point failures are given in each of the subsystem’s documentation. The following components have been identified as single point failure components in the CubeSat:
Power Storage (Li-ion batteries)
Example Failure Mode Analysis – COMM System, C&DH System and Stuctures.
Table 12. Failure mode analysis for Comm system.
Table 13 . Failure mode analysis for C&DH system.
Table 14. Failure mode analysis for Structures system.
Gantt Chart.
A Gantt Chart is a bar chart that can be used to allot time to tasks, schedule reviews, and date milestones. Tasks are the project activities. Tasks have start and end dates (e. g. “Create Structure”). Generally we write the task as a phrase starting with a verb (e. g. “creating product”). Each task has a start time and end time. The chart often needs to be updated since end dates are usually estimates and tend to slide (almost always later than earlier in real practice). Milestones are either checkpoints, due dates, dates for interim goals, or dates of reviews. Since the chart period is usually set in days, weeks, or months, meetings, reviews and milestones appear as single dots or bullets rather than a line for how long the item takes. See Chapter 2 for other examples.
The Gantt Chart is typically one of those SE “tools” that can make the slave of its master in real practice. If you knew exactly what tasks were needed, precisely how long each task really took and the proper order they would be done in, then the Gantt Chart could be properly used as a true gage of the engineering progress. If the real progress was ahead of the Gantt Chart, the team could be assumed exceptional and be given time off. If they were behind, they needed to stay late and get back on track. But that all assumes the chart indicates the true process. Only in rare circumstance is there sufficient information to get even a slightly accurate schedule laid out at the beginning of a technical project. Besides not knowing the design and what might be needed to integrate all the subsystems, things outside the project control are guaranteed to mess up the planning. Typical for aerospace projects are the funding availability (money must be there to hire engineers or pay the contractor), the procurement process (how long it takes to buy something), facility access (testing is often rescheduled due to other projects using a facility) and numerous technical issues. This “measuring stick” of project’s progress is not a precise yardstick that can be used to beat subsystem leads into doing their work! It is more accurately described as a loosely laid out bungee cord to which different people pick up at various points, each effecting the length and alignment of the rather inaccurately spaced measurement marks. Use the chart as a tool to help monitor and roughly gauge where a project stands. It is better than not having any idea of the task timing and it does make the system engineer aware of conflicts and product integration flow. Nonetheless, you could have the most exceptional engineering team that is far behind the original schedule with added tasks and missed milestones and the sorriest group of misfits right on the Gantt Chart schedule. You probably would still prefer to ride in the rocket the first group produced late, than launch on time with the second.
Figure 5. Gantt Chart showing schedule of tasks and their progress.
Outline of a Detailed Systems Engineering Management Plan (SEMP) for a Student Project (NASA, 2002)
The SEMP is a planning document that should be baselined by the Systems Engineer at the end of Phase A, and formally updated as needed thereafter. It primarily schedules activities and reviews, and assigns SE functions to individuals. The level of detail necessary here depends on the size of the team, scope of the project, etc. with the primary sections listed as follows:
(Include Mission Overview, Project schedule with life cycle and reviews.)
2. System Engineering Activities.
(Describe the overall lifecycle including the major systems engineering activities for each phase, irrespective of who does them. Describe critical decisions and activities such as Reviews.)
( Describe methods utilized for communicating systems engineering activities, progress, status and results.)
4. Systems Engineering Functions.
4.1 Mission Objectives.
(The Systems Engineer should be responsible for creating a team who are responsible for Level 1 Requirements and Mission Objectives.)
4.2 Operations Concept Development.
(The Systems Engineer defines who develops the operations concept, what format is planned and when it is due. Define who develops the ground based verification concept, what format is planned and when it is due.)
4.3 Mission Architecture and Design Development.
(Define who develops the Architecture and Design, what format is planned and when it is due. Define who develops and maintains the Product Breakdown Structure.)
4.4 Requirements Identification and Analysis.
(Define who develops the requirements hierarchy, define who is responsible for each part of the hierarchy, define who identifies and is responsible for the crosscutting requirements. Define when requirements identification is due and when formal configuration control is expected to start.)
4.5 Validation and Verification.
(Define who is responsible for the validation and verification activities and how this is accomplished.)
4.6 Interfaces and ICDs.
(Define which ICDs are planned, what interfaces are to be included, who is responsible for developing the ICDs and who has approval and configuration management authority.)
4.7 Mission Environments.
(Define the applicable mission environments, who is responsible for determining the mission specific environmental levels or limits, and how each environmental requirement is to be documented.)
4.8 Resource Budgets and Error Allocation.
( List the resource budgets that Systems Engineering will track, and when they will be placed under formal configuration management. )
4.9 Risk Management.
(Define who is responsible for defining acceptable risk and where this is documented. Define the role of systems engineering in risk management and how the analysis are to be accomplished.)
4.10 System Engineering Reviews.
(Define which system engineering reviews are planned and who is responsible for organizing them.)
5. Configuration Management.
(Define what systems engineering documentation is required and when it is to be placed under formal configuration management. Define the method to archive and distribute System Engineering information generated during the course of the lifecycle.)
6. System Engineering Management.
(Define the Systems Engineering Organization Chart and Job Responsibilities. Define trade studies, who does them and when they are due.)
AUSSP. (2007). AubieSat-1: Auburn's First Student-Built Satellite .
NASA. (1995). NASA Systems Engineering Handbook, SP-610S : PPMI.