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