시간을 내어 이 동영상을 시청해 주셔서 감사합니다.
나는 당신이 사용했거나 사용하려고 시도했기 때문에 여기에 있다고 가정합니다.
JMP 내의 수리 가능한 시스템 시뮬레이션 플랫폼입니다.
조금 더 배우고 싶을 수도 있습니다.
일이 있어서 답답할 수도 있어요
당신이 하려고 노력하고 있는 것, 당신이 할 수 없다고 생각했던 것.
그래서 오늘 제가 다룰 내용은
문서에 자세히 설명되어 있지 않은 사항입니다.
시행착오를 통해 배운 것들
문서에 없는 것,
개발자와 이야기하면서 배운 내용까지
플랫폼에 대해, 당신이 찾을 수 없는 것들
다른 방법으로.
나는 당신이 이 플랫폼에 어느 정도 노출되었다고 가정할 것입니다.
여러분이 신뢰도 분석에 대해 조금 알고 있다고 가정하겠습니다.
따라서 병렬 설정이 무엇인지 자세히 설명할 필요는 없습니다.
N 중 K인 것이 무엇인지 등등.
그래서 제가 다루고 싶은 많은 예가 있습니다.
많은 자료. 시작하자.
이제 실제로 살펴보기 전에
수리 가능한 시스템 시뮬레이션 플랫폼에 대한 개요를 알려드리겠습니다.
다행히도 여러분은 이전에 사용해 본 적이 있고 익숙할 것입니다.
우리는 세 가지 다른 구성 요소에 대해 이야기 할 것입니다
문서에 없는 구성 요소에 대한 측면
또는 문서에 잘 설명되어 있지 않습니다.
가장 먼저 이야기할 것은 블록입니다.
블록은 수리 가능한 시스템 시뮬레이션을 구축하는 데 사용됩니다.
병렬, N중 K, 대기.
따라서 각 블록에 대해 이벤트를 해당 블록과 연결할 수 있습니다.
이것이 우리가 보는 작은 주황색 블록입니다. 각 블록에 대해
나는 하나 이상의 결과나 행동을 연관시킬 수 있습니다.
이것이 우리가 보는 파란 점들입니다.
이것이 시뮬레이션을 구축하는 데 도움이 될 것입니다.
예를 들어, 블록이 언제 실패하는지 알고 싶을 수 있습니다.
해당 블록이 실패하면 해당 블록을 수리하고 싶을 수도 있습니다.
그 수리에는 40시간이 걸릴 수도 있습니다.
이것이 바로 이러한 RSS 다이어그램을 구축하는 아이디어입니다.
이야기부터 시작해보자
블록의 일반적인 속성 중 일부입니다.
하나의 매듭에는 6개의 서로 다른 블록이 있습니다.
이를 통해 다이어그램 내에서 여러 항목을 하나로 묶을 수 있습니다.
6개 블록 중 5개는 복합재입니다.
그들은 두 개 이상의 하위 단위로 구성되도록 만들어졌습니다.
JMP를 사용하면 하나의 하위 단위와 함께 사용할 수 있습니다.
그러나 실제로 사용 사례는 두 개 이상의 하위 단위로 구성된다는 것입니다.
이벤트와 액션은 블록 전체에 적용됩니다.
그래서 이것은 중요한 포인트입니다.
블록 내의 구성 요소는 개별적으로 처리할 수 없습니다.
대기 블록을 제외하고.
단일 배포판이 할당됩니다.
종합하면, 이 두 중요 항목은 수리와 같은 일이 다음을 의미합니다.
또는 하위 장치에 대한 유지 관리가 불가능합니다.
이러한 복합 블록 내에서.
전체 블록이 실패할 때까지 기다려야 합니다.
실제로 그 블록으로 무엇이든 할 수 있기 전에
블록을 수리하기 전에요.
블록 내에서 다른 분포를 원하는 경우
Standby를 제외하고는 그렇게 할 수 없습니다.
그리고 우리는 나중에 예제를 통해 그것에 대해 이야기할 것입니다.
모든 복합 블록에 대한 하위 단위,
시리즈 블록을 제외하고는 병렬입니다.
이러한 다양한 복합 블록을 차별화하는 것은
실행 중인 구성 요소의 수입니다.
블록이 언제 실패하는지, 그리고 블록이 어떻게 노화되는지.
그래서 저는 모든 복합 블록을 다루는 작은 테이블을 만들었습니다.
그리고 그 특성과 어떻게 다른지.
Standby를 제외한 모든 복합 블록에 대해
모든 구성 요소가 동시에 실행됩니다.
복합 블록을 사용하면 N개 장치 중 K개를 선택하여 실행할 수 있습니다.
그런 다음 나머지 유닛은 백업이 됩니다.
그렇다면 이러한 블록은 언제 실패합니까?
분명히 신뢰성에 대한 경험이 있다면 시리즈 블록은 실패합니다.
한 유닛이 고장났을 때.
모든 장치가 실패하면 병렬 블록이 실패합니다.
K개보다 적은 단위를 보유한 경우 N개 중 K개 등입니다.
따라서 신뢰도 분석에서 자연스럽게 기대할 수 있는 것들은
대기 및 공유에는 또 다른 실패 방법이 있습니다.
대기 장치에는 전환 메커니즘이 있습니다.
전체 블록에 하나의 스위치가 있을 수 있습니다.
또는 각 백업마다 하나의 스위치가 있습니다.
스위치가 하나만 있으면 대기 모드가 실패할 수 있습니다.
해당 스위치가 실패하거나 사용하려고 하면
내 백업 장치 각각
해당 백업 장치의 스위치도 작동하지 않습니다.
따라서 스위치 오류는 블록 오류의 또 다른 원인이 될 수 있습니다.
스트레스 공유도 마찬가지입니다.
하지만 스트레스 공유를 사용하면 스위치가 하나만 있습니다.
최종적으로 다른 특징
이 복합 블록 사이의 노화 방식입니다.
처음 3개 블록의 수명은 동일합니다.
블록 내의 모든 하위 단위는 동일하게 에이징됩니다.
대기 및 스트레스 공유의 경우 하위 단위가 노화될 수 있습니다.
대기 모드에서는 수명이 다르게 지정될 수 있습니다.
스트레스 공유의 경우 확실히 나이가 다릅니다.
대기의 경우,
내 운영 단위에 대해 단일 배포판을 선택하게 됩니다.
내 백업 장치의 경우
노화되지 않도록 선택할 수 있습니다. 그게 바로 콜드 스탠바이입니다.
아니면 다른 배포판을 제공할 수 있습니다.
대기 모드에 있을 때 어떻게 늙어가는지
또는 백업 역할을 할 때.
그것은 내 운영 단위가 다를 수 있는 것과 같을 수 있습니다.
그래서 저는 두 가지 다른 분포를 선택하게 됩니다.
문제는 또,
이 모든 복합 블록과 마찬가지로 하나의 분포를 얻습니다.
모든 운영 단위에 대해 모든 백업에 대해 하나의 배포를 수행합니다.
혼합하고 일치시킬 수 없습니다.
마지막으로 스트레스 공유를 통해 스트레스 공유가 작동합니다.
조금 다르게.
응력 공유를 사용하면 응력이 블록 간에 균등하게 분산됩니다.
그러나 하위 유닛 중 하나가 실패하면
추가 스트레스는 나머지 운영 단위와 관련이 있습니다.
그래서 스트레스는 실패에서 실패로 변합니다.
우리는 그 예를 잠시 후에 살펴보겠습니다.
이제 여러분이 발견했을 수도 있는 것 중 하나는
아니면 가끔은
당신은 좀 더 유연성을 갖고 싶어
유연성을 키울 수 있는 방법은 기본 블록을 배열하는 것입니다.
또는 병렬 또는 N 중 K와 같은 기본 블록
내 복합 블록 중 하나입니다.
기본 블록은 직렬, 병렬 또는 N중 K처럼 쉽게 배열할 수 있습니다.
대기 및 스트레스 공유 블록을 사용하기가 더 어렵습니다.
유닛이 2개 이상일 때.
잠시 후에 예를 들겠습니다.
두 개의 기본 블록이 있는 대기 설정을 보여줍니다.
이를 수행하는 방법은 비교적 간단합니다.
하지만 이를 세 블록으로 확장하려고 하면
훨씬 더 어려워집니다.
불가능하지는 않지만 매우 어렵습니다.
왜냐하면 무엇이 작동하고 무엇이 작동하지 않는지 추적해야 하기 때문입니다.
실패가 발생하면 어떻게 됩니까?
스트레스 공유에도 마찬가지입니다.
첫 번째 예를 살펴보겠습니다.
첫 번째 예에서는 기본적인 K out of N 배열을 살펴보겠습니다.
우리는 5개의 하위 유닛을 갖게 될 것입니다.
그 중 3개가 작동해야 합니다.
그들은 모두 알파가 2,000이고 베타가 1인 Weibull을 갖게 될 것입니다.
우리는 블록이 실패할 때를 가정하겠습니다.
교체하는데 40시간이 걸린다고 하네요.
우리는 그 배열을 넣을 것입니다
N개 중 K개의 복합 블록과 직렬로 연결됩니다.
또한 K out of N 복합 블록에는 40시간이 걸린다고 가정합니다.
5개의 하위 단위가 있음에도 불구하고 교체
실패한 해당 블록 내에서.
어떤 차이가 있는지 살펴보겠습니다
이것을 개별 품목으로 취급하는지 여부
아니면 내 복합 품목으로?
이것이 내 설정이 RSS에서 보이는 모습입니다.
나는 그것을 매우 간단하게 유지했습니다.
다음은 N 중 K에 상대적인 하위 단위입니다.
N 중에서 K를 만드는 것은 매듭에 있습니다.
들어오는 항목의 수를 지정할 수 있습니다
운영해야 합니다.
그리고 여기서는 3개의 수술이 필요하다고 말했습니다. 이것이 바로 N 중 K가 되는 이유입니다.
이 배열은 N 중 K입니다.
그리고 저는 아주 간단하게 설명하겠습니다.
제가 살펴볼 유일한 이벤트는 블록이 실패하는지 여부입니다.
제가 취할 유일한 조치는 새것처럼 수리하는 것입니다.
계속해서 이것을 실행해 봅시다.
비교적 빠릅니다.
출력에 대해 조금 이야기하고 싶습니다.
왜냐하면 출력과 상태로 전송되는 내용은
앞으로 다이어그램 작성을 시작할 때 도움이 될 것입니다.
작업 순서를 살펴보겠습니다.
이번 첫 번째 실패 때문에.
따라서 766시간 동안 Sub1 장치가 실패했음을 알 수 있습니다.
블록이 제거됩니다.
그것은 나의 잠재적인 사건 중 하나이기 때문에 주목하는 것이 중요합니다.
따라서 블록이 제거되고 프로세스가 시작되며 블록이 교체됩니다.
그리고 블록을 교체한 후, 제가 지정한 40시간이 지나면
내 설정에서는 시스템이 자동으로 켜집니다.
이것이 또 다른 중요한 점입니다.
우리는 상황에 직면하게 될 것입니다
내 이벤트 중 일부의 경우 시스템이
자동으로 켜지는데, 그게 어떤 것인지 이야기하겠습니다.
그러한 경우에 우리가 해야 할 일은 무엇입니까?
실제로 시스템을 켜거나 어떤 경우에는 블록이
자동으로 켜지지 않으면 수동으로 차단을 켜세요.
여기에는 Sub3 오류가 있고 유사한 일련의 이벤트가 표시됩니다.
Sub2가 실패합니다. 무슨 일이 일어나는지 살펴보겠습니다.
시스템이 다운되었을 때.
그리고 우리는 N 중 K가 실패할 때 그런 일이 확실히 일어난다는 것을 알고 있습니다.
좋습니다. 시스템이 실패한 첫 번째 사례는 다음과 같습니다.
다시 말하지만, 대부분의 작업과 관련하여 매우 유사합니다.
하지만 시스템이 다운된다는 것을 알게 될 것입니다.
시스템이 종료되었으므로 시스템을 종료해야 합니다.
시스템의 모든 블록을 끕니다.
다시 한 번 명심해야 할 중요한 사실은,
왜냐하면 우리가 알아야 할 경우가 있을 것이기 때문입니다.
블록이 켜져 있고 꺼져 있는지 여부.
블록을 수동으로 켜야 하는지 여부입니다.
그럼 여기서 교체 들어갑니다.
교체가 완료되면,
모든 블록이 자동으로 켜집니다.
그리고 다시 이것으로 새로운 것으로 교체하십시오.
끄고 켜는 작업은 모두 자동으로 이루어집니다.
그래서 나는 그것에 대해 걱정할 필요가 없습니다.
드디어 K out N 교체를 마쳤고 다음 실패까지 끝났습니다.
비교적 간단합니다.
내 시스템이 어떻게 작동하는지 살펴보고 싶다면
결과 탐색기를 시작하겠습니다.
기본적으로 구성 요소 수준 정보는 표시되지 않습니다.
구성 요소 수준 정보를 원하면 핫스팟으로 다시 돌아가야 합니다.
전체적인 옷을 원하면 고르세요.
구성 요소별로 가동 중지 시간을 선택하겠습니다.
이제 이 조직에서 명심해야 할 점은,
이건 그냥 나한테 말하는 거야
내 구성 요소와 관련된 시스템의 가동 중지 시간.
따라서 이것은 N 중 K가 시스템을 몇 번이나 다운시켰는지 알려줍니다.
이들 각각에 대해,
이는 해당 하위 유닛이 시스템을 중단한 시점에 해당합니다.
그러니 생각해보면 이것들은 시대에 부합한다.
하위 유닛이 5개 유닛 중 마지막 유닛이 무너졌을 때,
왜냐하면 그때가 시스템이 다운되는 유일한 시간이기 때문입니다
5개의 하위 단위가 모두 다운되는 경우입니다.
이제 구성요소 수준 분포를 살펴보려면
이는 시스템이 다운되는 경우에만 알려줍니다.
하지만 Sub1이 얼마나 자주 다운되었는지에 관심이 있다고 가정해 보겠습니다.
Sub2가 얼마나 자주 다운되었는지 등등.
핫스팟, 이 Point Estimation을 볼 수 있습니다
구성 요소 가용성을 위해.
예를 들어 Sub1의 경우 아래로 스크롤하면
이것은 내 배포 정보를 제공합니다
구성 요소 자체에 대한 것입니다.
Z에는 하위 장치 1이 시스템을 중단한 시간뿐만 아니라
하지만 Subunit 1이 자체적으로 다운되었을 때.
모든 하위 구성 요소의 개별 분포를 살펴보는 가장 쉬운 방법입니다.
다음 작업과 이벤트 중 일부를 살펴보겠습니다.
그리고 그와 관련된 특정 속성 중 일부.
이벤트부터 시작하겠습니다.
문서에 언급되지 않음
그러나 Inservice는 Basic 블록에만 사용할 수 있습니다.
다시 말씀드리자면 Inservice는 블록의 수명을 기준으로 합니다.
시뮬레이션 당시의 나이가 아닙니다.
예를 들어, 내가 뭔가 서비스를 제공하고 싶다면
100시간 사용 후에는 Inservice를 사용하겠습니다.
그렇지 않으면 예약된 이벤트만 사용할 수도 있습니다.
예정된 이벤트는 주 1회 서비스되며,
하지만 Inservice는 기본 블록에서만 사용할 수 있습니다.
Inservice를 사용하고 싶은지 알려주면
나는 이러한 기본 블록을 구축해야 할 것입니다.
초기화, 블록 실패 및 시스템 다운
각 블록마다 한 번만 사용할 수 있습니다.
그래서 여러분이 보게 될 것은 여러분이 그것들을 사용할 때,
이벤트 팔레트에서 사라지므로 더 이상 표시되지 않습니다.
따라서 이 기능은 한 번만 사용할 수 있습니다.
행동에 대해 이야기합시다.
사용할 수 있는 작업은 13개입니다.
Install Used, Change Distribution 및 If는 기본 블록에서만 사용할 수 있습니다.
Minimal Repair는 Basic 및 Series에서만 사용할 수 있습니다.
이제 모든 블록에 사용할 수 있는 9가지 작업이 남았습니다.
그래서 그들은 블록을 켜고 끄는 것, 시스템을 켜고 끄는 것,
새 것으로 교체, 새로 설치, 블록 제거, 오류 검사,
및 일정. 그럼 저게 9개야
기본 블록이나 복합 블록 중 어느 블록이든 사용할 수 있습니다.
특정 블록에 작업을 사용할 수 있는 횟수에는 제한이 없습니다.
그래서 Turn Off Block을 두 번 이상 사용한 예가 있습니다.
그 이유는
돌린 후 하고 싶은 일이나 블록을 켰을 때 하고 싶은 일이 다를 수 있습니다
블록이 언제 켜지는지에 따라 다릅니다.
그리고 다시, 우리는 그 예를 조금 후에 보게 될 것입니다.
작업은 다른 작업에만 연결할 수 있습니다.
실제로 이벤트는 액션에만 연결될 수 있습니다.
그래서 이벤트나 액션을 블록이나 다른 이벤트에 연결할 수 없습니다.
그러나 함께 연결할 수 있는 작업 수에는 제한이 없습니다.
몇 가지 특정 속성.
초기화는 한 번만 발생하며 맨 처음에 수행됩니다.
시뮬레이션 실행 중.
차이가 나는 예를 하나 들어보겠습니다.
초기화 시 블록을 끄는 경우
하지만 시스템이 다시 온라인 상태가 되면 해당 블록은 다시 켜집니다.
그래서 수동으로 꺼야 합니다.
따라서 초기화는 처음에만 발생합니다.
System is Down은 모든 블록에서 발생하며,
어떤 블록이 시스템을 다운시켰는지에 관계없이 말이죠.
그래서 나는 그것을 청취자로 사용하여 볼 수 있습니다 ...
예를 들어 시스템이 다운되면
블록이 실패하더라도 블록에 대한 유지 관리를 수행하고 싶을 수도 있습니다.
실행 중이었는데 어쩌면 다시 시작하려고 그랬을 수도 있습니다.
거의 새것으로 만들거나 새것처럼 다시 가져옵니다.
따라서 어떤 블록이 시스템을 다운시켰는지에 관계없이 시스템 다운이 발생합니다.
그러면 행동에 대해서,
시스템을 켜면 사용 가능한 모든 블록이 켜집니다.
이제 모든 블록이란 아직 다운되지 않은 모든 것을 의미합니다.
장애로 인해 또는 다운될 예정입니다.
그래서 난 뭔가를 중단하도록 일정을 잡을 수 있었어
예약된 이벤트를 사용하거나 예약된 작업을 사용합니다.
시스템을 켜면 내 모든 블록이 켜집니다.
블록을 수동으로 켜야 함
새로 설치, 중고 설치 또는 배포 변경 후.
시스템이 켜지지 않는 경우가 몇 가지 있습니다.
블록이 자동으로 켜지지 않습니다.
이것이 내가 사용하고 싶은 이유입니다.
예를 들어 새 항목으로 바꾸기 대신 새 항목을 설치합니다.
Install New를 사용하면 시스템을 다시 켜기 전에 작업을 수행할 수 있습니다.
다른 작업을 수행할 수 있는 기회를 제공합니다.
또는 시스템을 켜기 전에 다른 작업을 수행합니다.
블록 켜기는 블록을 수동으로 끈 경우 시스템을 켜지 않습니다.
출력에서 본 것처럼,
출력에서 알 수 있듯이 시스템이 켜져 있는지에 관계없이
시스템 켜기 이벤트가 나타날 수 있습니다.
시스템이 이미 켜져 있는 경우에는 시스템을 켜도 문제가 되지 않습니다.
내가 말하는 것은 의심스러운 경우 시스템 켜기(Turn on System)를 추가하라는 것입니다.
이벤트 체인에 연결하여 시스템이 켜져 있는지 확인하세요.
그런데 블록을 먼저 켜도 상관없습니다
또는 시스템이 먼저 켜져 있습니다.
둘 다 같은 방식으로 작동합니다.
좋습니다. 두 번째 예로 넘어가겠습니다.
우리가 할 일은 기본 블록을 만드는 것입니다.
대기 배열에서.
우리는 하나의 기본 장치와 하나의 대기 장치를 갖게 될 것입니다.
콜드 스타트업을 하려고 합니다.
이는 대기 장치, 즉 백업 장치가 노후화되지 않음을 의미합니다.
그러나 장치를 시작하는 데 30분이 소요됩니다.
복합 대기로는 할 수 없는 일이 있습니다.
제어 후 8시간 동안 백업에 대한 유지 관리가 수행됩니다.
다시 본체로 전달됩니다.
우리는 두 가지 다른 스위치 상황을 살펴보겠습니다.
우리는 실제로 오류가 없는 스위치를 살펴보고
90%의 신뢰도를 갖고 있는 스위치를 살펴보겠습니다.
모든 블록에 대해 지수(500)를 가정하겠습니다.
수리하거나 유지하는 데 8시간이 걸릴 것으로 예상합니다.
실패한 블록은 새로운 블록으로 교체됩니다.
이전 예와 마찬가지로 기본 블록을 살펴보겠습니다.
동일한 설정을 가진 대기 블록과 직렬로 배열된 경우,
분명히 시작 시간 30분을 제외하고는
나는 할 수 없습니다.
한 번 보자.
기본 배열은 다음과 같습니다.
백업 장치, 기본 장치, 대기 장치가 있고 이들 각각에 대해
실패 이벤트와 새 항목으로 바꾸기를 연결했습니다.
내가 시작할 수 있는 것의 기본 뼈대입니다.
이전에 출력을 볼 때 지적했는지는 모르겠습니다.
하지만 이벤트를 추가할 때 도움이 됩니다. 고유한 이름을 지정하는 작업을 추가하세요.
왜냐하면 그것이 내 출력에 나타나는 이름이기 때문입니다.
좋습니다. 백업 장치부터 시작하겠습니다.
내 시스템이 0시에 온라인 상태가 되면 모든 것이 켜질 것입니다.
저는 시간이 0이 되면 해당 백업 장치가 꺼지는지 확인하고 싶습니다.
제가 할 방법은 초기화를 사용하는 것입니다.
초기화를 사용했을 때,
그것은 사라졌다.
다음으로 하고 싶은 일은 블록을 끄는 것입니다.
자, 이전에 RSS를 사용해 본 적이 있다면,
제가 액션을 추가하려고 하면
이러한 작업을 서로 겹쳐서 쌓을 것입니다.
때로는 그곳이 그들에게 가장 적합한 위치가 아닐 때도 있습니다.
작업할 작업이 하나 있을 때 언제든지 할 수 있는 작업,
작업을 선택하고 이 더하기 기호를 길게 클릭하면 됩니다.
그런 다음 플러스를 드래그하면 됩니다.
이제 작업을 추가할 수 있습니다.
이 경우에는 차단을 해제하고 싶습니다.
이제 이와 관련된 끄기 블록을 원하지 않고 새로 교체합니다.
이런 일이 발생하지 않도록 제가 할 일은 화살표를 삭제하는 것뿐입니다.
이제 내가 원하는 이벤트에 접속할 수 있습니다.
그렇게 하면 이제 해당 블록을 원하는 곳 어디든 이동할 수 있다는 장점이 있습니다.
블록이 작동하는 방식에 훨씬 더 많은 유연성이 있습니다.
제가 하려는 또 다른 일은 이것들에 라벨을 붙이고 싶다는 것입니다.
그래서 결과표를 보면 어떤 일이 일어나는지 알 수 있습니다.
차단 해제입니다...
시작 시 백업 끄기를 호출해 보겠습니다.
나는 내 이벤트와 행동 각각에 고유한 이름을 부여할 것입니다.
그래서 언제 그런 일이 일어나는지 압니다.
그러면 처음에는 백업이 꺼집니다.
다음으로 하고 싶은 일은 본체가 고장났을 때,
백업 장치를 켜려고 합니다.
이제 다시 백업 장치를 선택하고 차단 켜기라고 하기보다는,
대화형으로 차단 켜기를 선택하겠습니다.
이것을 이동할 수 있도록 여기에서 연결을 삭제하겠습니다.
내용을 조금 옮겨보겠습니다.
이걸 바로 여기로 옮기겠습니다.
다시 한 번, 이 다이어그램으로 돌아오면 이름을 지정하고 싶습니다.
며칠만 지나면 이 행동이 무엇과 연관되어 있는지 알 수 있습니다.
이것을 메인에서 백업 켜기라고 부르겠습니다.
문서에 언급된 또 다른 사항은,
하지만 얼마나 강한지는 모르겠지만 연결할 수는 있어요.
이 경우에는 한 블록의 이벤트를 작업에 연결합니다.
다른 블록에.
나는 확실히 그렇게 할 수 있습니다.
이제 앞서 언급했듯이 블록이 켜집니다.
해당 블록이 수동으로 꺼졌기 때문에
시스템도 켜야겠습니다.
시스템을 켜십시오.
다시 한 번 말씀드리지만, 저는 아마도 이렇게 라벨을 붙이고 싶습니다.
백업에서 시스템 켜기 등을 말씀드리겠습니다.
이제 다이어그램에 추가해야 할 유일한 것은
내 메인이 다시 온라인 상태가 되면 백업을 끄고 싶습니다.
내 백업을 유지 관리하세요.
이제는 아마도...
자, 우선 백업을 끄고 차단을 끄겠습니다.
삭제하세요.
우리는 이것을 부를 것입니다.
켜기를 선택했어야 했는데 끄기 차단이 선택되었습니다.
다시 시도해 보겠습니다.
차단 및 레이블을 끄고 기본에서 백업을 끄십시오.
내 메인이 온라인으로 연결되는 곳이 있습니다.
거기에서 백업을 껐습니다.
유지 관리를 수행하고 싶습니다.
제가 할 방법은 새 것으로 교체하는 것입니다.
좋아요, 우리는 이것을 예방적 유지보수라고 부르겠습니다.
예방정비를 한다고 말한 것 같은데
8시간이 걸립니다.
이제 다시 기억해야지
새 항목으로 바꾸기가 자동으로 블록을 시작합니다.
이제 내가 해야 할 일은 블록을 끄는 일이다.
이제 좀 더 자세히 생각해보면,
아마 새로 돌아온 온라인에서 바로 나갈 수도 있었을 텐데
유지관리를 하라고.
백업 유지 관리를 시작하면 백업 작동이 중지되기 때문입니다.
그런 다음 유지 관리가 끝나면
블록을 끄십시오.
이 블록은 해롭지 않지만 중복됩니다.
그러니 그냥 없애자.
그것이 내 설정이 될 것입니다.
나는 항상 일이 제대로 작동하는지 다시 확인하기 위해 달려가는 것을 좋아합니다.
올바른 순서로 출력을 생성하겠습니다.
이 경우에는 한 번의 시뮬레이션만 수행하도록 설정했습니다.
한두 개 정도는 가져가야 할 것 같아
내 장치와 관련된 신뢰성에 따른 시뮬레이션.
주요 실패는 다음과 같습니다. 시스템이 꺼집니다.
대기 블록을 끄고 새 메인 블록을 넣고,
메인 백업을 켜세요.
포식자 열을 보면 메인에 대한 백업이 켜져 있는 것을 알 수 있습니다.
백업에서 시스템을 켜고 시스템별 차단을 켭니다.
다시 한 번 말씀드리지만, 일단 구축한 후에는 이를 단계별로 확인하여 확인하고 싶습니다.
일이 올바른 순서로 일어납니다.
턴 시스템이 켜집니다.
새로운 메인이 들어왔습니다.
시스템을 켜보니,
다시 말하지만, 이미 켜져 있지만 중요하지 않고 아프지 않습니다.
새로운 메인 새로운 것으로 교체합니다.
그게 바로 블록이고, 백업이 돌아가고 있는 중이야
PM을 받는 것 등등.
해당 백업이 꺼져 있어야 합니다.
다시 한 번 말씀드리지만 저는 이를 다시 확인하는 데 사용하는 것을 좋아합니다.
일이 제대로 작동하도록 만드는 것입니다.
스위치가 없는 구성입니다.
스위치를 추가하는 방법은 비교적 간단합니다.
우리가 그것을 놓을 곳에, 우리는 그것을 놓을 것입니다
주요 실패와 백업 시작 사이
이것이 바로 if 블록이 만들어진 이유입니다.
그 연결을 제거하겠습니다.
내 블록 중 어느 블록에서 왔는지는 중요하지 않습니다.
그리고 나는 그것을 거기에 넣고 싶지 않았습니다.
나부터 놔줘...여기 있습니다.
혹시라도 그런 일이 일어날 경우를 대비해서 백업해 두었어요.
여기 있습니다.
내 백업이 켜져 있습니다.
내 주요 실패가 있습니다.
우리는 그것을 제거할 것입니다.
아마도 if 블록을 추가하여 어디든 띄울 수 있을 것입니다.
나는 이것들 중 하나를 선택하고 if를 추가할 것입니다.
연결을 삭제합니다.
그걸 연결해 봅시다.
이제 내가 설정하는 방식은 다음과 같습니다.
if가 작동하는 방식은 if 조건 상자에 있는 내용을 평가하는 것입니다.
그것이 사실이고 1로 평가되면 계속 진행합니다.
0으로 평가되면 중지합니다.
내가 말할 수 있는 것은 만약에... if 거기에는 필요하지 않습니다.
나는 무작위 균일이 0.9보다 작다고 말할 것입니다.
그것이 사실이라면 체인은 계속될 것이고, 그렇지 않으면 거기에서 멈출 것입니다.
그게 다야.
if 문에 넣는 것은 매우 간단합니다.
다시 말하지만, 아마도 이것도 라벨을 붙이고 싶을 것입니다.
따라서 스위치가 성공하거나 그와 유사한 경우입니다.
이 시점에서 유일한 단점은 스위치가 실패하면 어떻게 될까요?
음, 스위치가 실패했습니다. 메인이 다시 온라인 상태가 될 때까지 기다려야 합니다.
메인이 다시 온라인 상태가 되면 백업을 끄려고 합니다.
이미 꺼져 있는 것을 끄려고 해도 문제가 되지 않습니다.
하지만 내가 하고 싶지 않은 일이
백업이 사용되지 않으면 유지 관리를 수행하고 싶지 않을 수도 있습니다.
나중에 예를 들어 이 문제를 해결하는 방법을 알아보겠습니다.
시스템을 조사하여 해당 백업이 실행 중인지 확인하는 방법은 무엇입니까?
실행되지 않으면 유지 관리를 수행하세요.
실행 중인 경우 유지 관리가 필요하지 않습니다.
다음 예시로 넘어가겠습니다.
이 경우 예방 유지보수를 위해 두 개의 펌프를 병렬로 작동하고 있습니다.
2주마다 8시간씩 수행됩니다.
PM은 두 펌프가 모두 다운되는 것을 방지하기 위해 일주일 간격으로 시차를 둡니다.
동시에.
펌프에 장애가 발생하면 최소한의 수리만 수행되며 4시간이 소요됩니다.
이 경우 시뮬레이션은 1년 동안 실행됩니다.
여기서 맨 뼈부터 시작해 보겠습니다.
펌프 고장 및 교체가 발생한 펌프는 다음과 같습니다.
PM을 시작하기 일주일 전 대기 시간을 어떻게 설정하나요?
마지막 예시처럼 초기화부터 시작하겠습니다.
내가 말하려는 것은 일주일을 기다리라는 것이다.
일주일만 기다리라고 어떻게 말하나요?
음, 제가 할 일은 일정 작업을 사용하는 것입니다.
나는 과거에 해왔던 일을 할 것입니다.
일정을 설정하고 연결을 삭제하겠습니다.
일정에는 다양한 옵션이 있습니다.
이런 일이 딱 한 번만 일어나길 바라요. 처음부터 그런 일이 일어나길 바라요
그래서 그것은 내 초기화 이벤트에 연결되어 있습니다.
일주일 정도 기다리도록 하겠습니다.
이런 일이 딱 한 번만 일어나길 바라요.
168시간이 걸리기를 원합니다.
몇 시간 만에 시뮬레이션을 설정했기 때문입니다.
그 일은 시작부터 일주일을 기다립니다.
그런 다음 여기에 연결하는 모든 작업을 수행합니다.
내가 연결할 작업은 무엇입니까?
음, 다시 일정을 사용하겠습니다.
이것은 펌프 2의 PM이 될 것입니다.
최대 발생 횟수를 비워 두겠습니다.
그래서 시뮬레이션이 끝날 때까지 이를 수행합니다.
완료 시간은 168x2이므로 336이 됩니다.
이제 일어나는 일은 첫 번째 주 이후 매 336시간마다
나는 또 다른 수술을 할 수 있게 될 것이다.
그 작업은 이를 수행하는 몇 가지 다른 방법입니다.
우리는 PM [들리지 않음 00:37:03]이라고 가정하겠습니다.
그래서 우리는 New로 교체한다고 말할 것입니다.
여기서는 펌프 B를 교체하라고 말할 수 있습니다.
이제 여러분이 생각할 수 있는 것 중 하나는
예방정비를 하러 가면 어떻게 되나요?
모든 것이 시차를 두고 있지만 어떤 이유로든 펌프 A가 작동하지 않습니다.
실패했을 수도 있습니다.
펌프 B를 반드시 내려놓을 필요는 없습니다.
예방 정비를 위해.
그렇게 하고 시스템을 무너뜨리세요. 우리가 사용할 것은 다음과 같습니다.
시뮬레이션 컨텍스트라는 숨겨진 변수를 사용합니다.
시뮬레이션 컨텍스트는 내 시스템을 살펴볼 수 있는 방법입니다.
우리가 할 일은 시뮬레이션 컨텍스트를 넣는 것입니다.
예정된 유지 관리와 실제 예방 유지 관리 사이에 두겠습니다.
이렇게 해보자.
이를 제거하고 if를 사용하여 구현하겠습니다.
연결하고 이것을 호출하겠습니다. 펌프 A가 작동하면
이제 문제는 펌프 A가 작동하는지 어떻게 알 수 있느냐는 것입니다.
음, if 조건에서 숨겨진 변수를 지정해야 합니다.
그것은 펌프 A와 연관되어 있습니다... 활동적이든 아니든 말이죠.
내가 할 방법은 시뮬레이션 컨텍스트입니다.
대소문자는 중요하지 않습니다.
시뮬레이션 컨텍스트 및 변수,
시스템 변수는 배열의 연관 항목으로 저장됩니다.
이것을 펌프 A의 상태라고 합니다.
이제 내가 찾은 것은,
대화 상자의 이 특정 부분은 그다지 유연하지 않습니다.
내가 만들고 싶은 좀 더 복잡한 것이 있다면,
그러면 보통 스크립트 창에서 하고 복사해서 붙여넣는 거죠.
이 창으로 들어갑니다.
하지만 이것은 상대적으로 작으므로 그냥 입력하겠습니다.
우리는 이것이 활성화되어 있다고 말할 것입니다.
그것이 내가 사용할 것입니다.
자, 그것이 내가 사용해야 하는 것임을 어떻게 알았습니까?
글쎄, 밝혀진 바와 같이 이것은 조건과 약간의 경우입니다.
나중에 스트레스 공유에 관해 이야기할 때
이것은 스크립트처럼 작동합니다.
내가 할 수 있는 일과 자주 했던 일
인쇄된 명세서에 기재되어 있는데, 제가 이용할 수 있는 것이 무엇인지 어떻게 알 수 있습니까?
거기에 인쇄문을 넣어보자
그리고 우리는 인쇄 시뮬레이션 컨텍스트라고 말할 것입니다.
우리가 확신해야 할 유일한 것은
if 문은 해당 if 조건의 마지막 문이 true를 평가한다는 것입니다.
무슨 일이 일어나는지 보여주기 위해
이 작업을 수행하면 그냥 실행해 보겠습니다.
나는 당신에게 아이디어를 주기 위해 그것을 실행할 것입니다
로그에 인쇄되는 내용.
계속해서 내 기록을 가져오면 다른 기록 중 하나에서 끝납니다…
자, 내 로그가 있어
우리가 간다.
이것이 로그에 인쇄된 내용입니다.
사용 가능한 모든 변수에 대한 정보를 제공합니다.
이 특정 다이어그램에 대한 시뮬레이션 컨텍스트에서.
거기에 더 많은 블록, 더 많은 행동, 더 많은 이벤트를 넣었다면
그런 다음 해당 항목이 표시되고 해당 정보도 표시됩니다.
하지만 이건 좋은 방법으로 말해요
내 시스템에는 무엇이 있고 내가 액세스할 수 있는 변수는 무엇입니까?
여기서 기억해야 할 중요한 점은
이것을 읽을 수는 있지만 이 특정 변수에 다시 쓸 수는 없습니다.
시뮬레이션에서 내용을 변경할 수 있는 옵션이 없습니다.
하지만 나는 그 정보를 사용할 수 있어요.
마지막 예로 돌아가서, 내가 할 수 있었던 일
거기에 if 문을 넣을 수도 있었나요?
내 백업이 활성화되어 있으면
그럼 소리를 줄이고 유지 관리를 하세요.
좋아요.
이제 시간 관계상 다음으로 넘어가겠습니다.
마지막 정보를 여러분과 공유하고 싶습니다.
그런데 일지를 사용할 수 있게 할게요.
쓸 수 있는 글이 있어야 하고,
시간이 없어서 다루지 못한 더 많은 예를 다루겠습니다.
몇 가지 작업을 더 볼 수 있습니다.
구현 방법을 살펴볼 기회가 없었습니다.
그리고 아마도 다른 것들도 있을 거예요
그것은 매우 간단하지 않을 수도 있습니다.
사용자 정의 스트레스 공유는 기본적으로
스트레스는 하위 단위들 사이에서 균등하게 공유됩니다.
이 블록의 수명을 변경하여 구현됩니다.
배포를 명시적으로 변경하지 않습니다.
스트레스 공유가 없을 때 n개의 하위 단위가 병렬로 있다고 가정해 보겠습니다.
첫 번째는 1번에 실패하고, 두 번째는 2번에 실패하는 식으로 진행된다고 가정해 보겠습니다.
스트레스 공유로 블록을 에이징하는 방식
즉, 첫 번째 실패는 t번 n번 발생합니다.
작업 단위 수를 곱합니다.
두 번째는 블록을 추가로 n - 1로 에이징합니다.
첫 번째 실패와 두 번째 실패의 차이를 곱한 것입니다.
세 번째는 n - 두 배의 차이입니다.
세 번째, 두 번째 실패 등등.
그것이 블록이 노화되는 방식입니다.
이는 해당 사용자 정의 함수에 전달되는 정보입니다.
이것을 스트레스 공유에 포함하려고 하면,
좋습니다. 이것이 어떻게 설정되는지에 대한 마지막 예를 여러분과 공유하겠습니다.
나의 예를 찾아보겠습니다.
좋아요, 여기에는 세 가지 다른 스트레스 공유가 있습니다.
기본적인 스트레스 공유가 있으므로 이를 기본으로 설정했습니다.
내 관습은 다음과 같습니다.
이것이 내가 말하는 끝입니다.
이 로그 기능에 포함되어 있음을 알 수 있습니다.
블록의 노화가 일치하도록 그렇게 이루어졌습니다.
맞춤형 스트레스 공유 블록에 사용할 수 있는 분포를 사용합니다.
내가 하는 일은 내 설명의 관점에서 사물을 생각하는 것입니다.
첫 번째 단위는 시간의 몇 배의 배수로 노화됩니다.
두 번째는 몇 배의 차이를 곱한 것입니다.
첫 번째와 두 번째 실패 횟수 등등.내 생각엔 그런 것 같아
이 모든 것에 대해.예를 들어, 내가 설정하고 싶다고 가정해 보겠습니다.
글쎄요, 거기 가기 전에 간단히 말씀드리자면,
if 블록과 마찬가지로 여기에 인쇄 문을 넣을 수 있습니다.
여기에 인쇄문을 넣으면,
시스템이 시작되기 전에 이것이 실행된다는 것을 알 수 있습니다.
그래서 5개를 인쇄할 것이고 5개를 인쇄할 것입니다.
왜냐하면 이 경우 블록에는 5개의 단위가 있기 때문입니다.
첫 번째가 실패하면 5개를 인쇄하려고 합니다.
그것은 함수 인쇄 4로 다시 돌아갈 것입니다.
등등, 등등.
이것을 블록이 사용자 정의 실패로 설정하고 싶다고 가정해 보겠습니다.
5배가 아닌 10배로 늙어가는 속도,
두 번째는 5세, 세 번째는 3세입니다.
두 번째는 1살이 되고,
마지막 사람은 과도한 스트레스를 받고 두 배나 빨리 늙어갑니다.
내가 할 수 있는 일은,
다시 한번, 이것을 여기에 넣자.
약간의 공간을 추가하겠습니다.
그리고 내 상자를 좀 더 크게 만들어 보세요.
다음과 같은 것을 넣을 수도 있습니다.
다시 한 번 말씀드리지만, 저는 그 로그를 넣고 싶습니다. 그 로그는 거기에 있어야 합니다.
로그인하면 선택과 같은 말을 할 수 있습니다.
n을 기반으로 choose가 수행하는 작업은 반환됩니다.
어디 보자, 하나의 단위가 있을 때 나는 그것이 절반을 반환하고, 하나는 두 개의 단위로 반환되기를 원합니다.
3개 단위로 2.5를 가정해 보겠습니다.
4개 단위로 5개, 마지막으로 10개.
이것이 바로 맞춤형 스트레스 공유를 만드는 방법입니다.
나는 이 선택 기능에만 국한되지 않습니다.
여기 이 특별한 예가 있습니다.
기능을 사용하고 있습니다.
자, 또 여기서 중요한 건
이 모든 것이 이 로그 함수에 포함되어 노화가 발생한다는 것입니다.
블록과 분포가 일치할 수 있습니다.
좋아요, 안타깝게도 오늘 제가 다룰 시간은 그게 전부입니다.
시간이 더 있었으면 좋겠어요. 확실히 많네요
우리가 이야기할 수 있는 다른 것들에 대해.
제가 제공한 자료에 그런 내용이 있을 겁니다.
그리고 나는 당신의 피드백을 듣고 싶습니다
그리고 당신이 가지고 있는 질문과 의견.
시간을 내주셔서 다시 한 번 감사드립니다. 이것을보세요.
이것이 정말 유익하길 바랍니다. 감사해요.
