ОБЪЕКТ-АНАЛИЗ

В работе рассматривается метод предварительного анализа технической системы (ТС) на стадии перехода от административного противоречия к техническому с целью определения возможных направлений решений поставленной задачи. Предлагаемый метод условно назван объект-анализом.

Предварительный анализ технической системы, объект-анализ

Введение

При постановке задачи для решения ее методами ТРИЗ сначала формулируется административное противоречие (АП) - проблема, требующая решения, но (пока еще) неизвестно - как.

В настоящее время основным способом перехода от АП к техническому является построение причинно-следственных цепочек (ПСЦ), определение ключевых недостатков и дальше - формулирование противоречий (технического и физического), приемы разрешения которых известны.

Построение ПСЦ - очень сильный инструмент, в то же время требующий глубокого и достаточно длительного анализа ТС.

В настоящей работе предлагается метод предварительного анализа технической системы (ТС), который может быть использован на ранней стадии анализа ТС для определения каких-либо возможных направлений решения поставленной задачи. При этом предполагается, что решение задачи потенциально может быть получено без каких-либо специальных изменений ТС, исключительно "внутри" существующих объектов самой ТС и имеющихся ресурсов. Предлагаемый метод условно назван "Объект-анализом".

Всегда можно найти решение внутри имеющейся ТС!

Назначение объект анализа

Объект-анализ - анализ ТС на стадии перехода от административного противоречия к техническому с целью определения возможных направлений решений поставленной задачи.

Объект-анализ является самостоятельным вспомогательным инструментом предварительного анализа ТС, не исключающим использование других способов решения задачи, и позволяет:

1) определять возможные направления решения поставленной задачи в рамках (определенного) состава ТС и имеющихся (потенциальных) ресурсов, или

2) корректировать первоначальную формулировку поставленной задачи для лучшего понимания сути проблемы

Результаты объект-анализа могут использоваться для формулирования предварительных концепций, для проведения полноценного функционально-ориентированного поиска (ФОП), для патентного поиска, для анализа указателя физэффектов и т.д.

В основе объект-анализа:

1) Аналогия "из жизни": для быстрого решения возникшей проблемы обычно используется то, что в данный момент находится "под рукой".

2) Аналогия "природная": всегда есть ненулевая вероятность осуществления какого-то события без какого-либо специального (преднамеренного) вмешательства со стороны.

Для описания объект-анализа вводится понятие "целевая функция" - результат, который мы хотим достичь при решении проблемы (задачи) и который потенциально может быть достигнут без специального вмешательства со стороны.

Очевидно, что реализации требуемой целевой функции либо мешает, либо может помочь существующий компонент/ресурс ТС. На самом деле конкретное влияние при объект-анализе не так важно, и заранее нельзя указывать какое именно действие - положительное или отрицательное - оказывается.

В объект-анализе для определения возможных направлений решения поставленной задачи рассматривается "композиция" наличия/отсутствия определенных объектов/ресурсов, которые потенциально могут мешать и/или помогать реализации целевой функции. Анализ набора таких композиций позволяет предварительно определить возможные направления решения задачи. В этом заключается суть объект-анализа.

Обоснование метода

Почему возникает какая-то проблема? Потому что что-то происходит не так, как нам хотелось бы. Почему происходит не так (не то), как нам хотелось бы, если в природе возможно даже самое невероятное? Потому что, нужное нам событие (которое пусть с очень малой, но ненулевой вероятностью вполне может произойти) невозможно заранее предсказать достаточно достоверно. И если бы было возможно предсказать, если бы было возможно управлять случайными событиями, то нужное нам решение получалось бы без изменения ТС.

Таким образом, в основе объект-анализа находятся два взаимосвязанных положения:

1) выполнение сформулированной в исходной задаче целевой функции может быть обеспечено без специального вмешательства

2) на выполнение целевой функции может влиять только наличие/отсутствие какого-либо объекта (компонента ТС или какого-либо имеющегося ресурса).

Пояснение: "наличие/отсутствие объекта" может означать как его предполагаемое физическое устранение из системы; так и (обычно) переход этого объекта из одного "крайнего" состояния (положения) в другое. Эти "крайние" состояния каждого объекта определяются в начале анализа и могут корректироваться по его результатам (н-р, пружина может быть а) растянута или б) сжата, и никакое другое "промежуточное" состояние пружины в рамках объект-анализа не принимается во внимание) Пример: Если пометить одну спичку в спичечном коробке, а потом высыпать все спички из коробка на стол, то помеченная спичка может оказаться в любом месте полученной кучки из спичек. Но нам нужно, например, чтобы помеченная спичка оказалась отдельно от других спичек, чтобы мы могли ее легко найти и взять в руки (целевая функция). Почему же в итоге она оказалась в другом месте, а не там, где нам надо? Потому что что-то помешало спичке оказаться отдельно от других спичек! Но с течением неограниченно длительного времени (с некоторой ненулевой вероятностью) нужная спичка вполне может оказаться отдельно от других спичек и без какого-либо специального вмешательства в ТС, состоящую из спичек, стола (какой-то поверхности) и т.д., только лишь в силу "случайного" (или псевдослучайного) воздействия каких-то внешних факторов (н-р, вибрации, потоков воздуха, любопытства постороннего человека и т.д.).

Общий принцип объект-анализа

Для любого объекта (компонента/ресурса ТС) всегда можно сформулировать условное технические противоречия (ТП) по форме:

ТП-1: Если объект N будет находиться в состоянии "1", то поставленная задача решится, но.... (потребуется выполнить большие изменения в ТС)

ТП-2: Если объект N будет находиться в состоянии "2", то поставленная задача не решится, но... (не нужно будет выполнять изменений в ТС)

(примечание: "объект N" - любой компонент ТС либо имеющийся ресурс)

Вторая часть ТП (после "но"..) в данном случае не важна, так как в объект-анализе деклрируется, что решение поставленной задачи "находится" внутри самой системы на гране перехода объекта N из одного состояния в другое, и изменений ТС выполнять не нужно. Поэтому из двух ТП формулируется объединенная задача: как сделать так, чтобы задача решалась, когда объект N находится в состоянии "1", и задача не решалась, когда объект N находится в состоянии "2"?

Кроме того, формулируется объединенная задача наоборот (обратная формулировка объединенной задачи может (и чаще всего так и есть) дает другое дополнительное направление для решения): как сделать так, чтобы задача решалась, когда объект N находится в состоянии "2", и задача не решалась, когда объект N находится в состоянии "1"?

Например, если требуется, чтобы ТС выполняла некоторую функции в соответствии с заданными критериями, тогда:

1) Формулируется объединенная задача: выполнение требуемой функции обеспечивается, когда объект N находится в состоянии "1" (а это именно то, что нам нужно!) и не обеспечивается выполнение требуемой функции, когда объект N находится в неком противоположном состоянии "2" (что вполне логично, т.к. возможно именно эта проблема изначально и привела к проблеме!)

2) Формулируется объединенная задача наоборот: выполнение требуемой функции обеспечивается, когда объект N находится в состоянии "2" и не обеспечивается выполнение требуемой функции, когда объект N находится в состоянии "1".

3) Анализируются обе задачи и формулируется возможные идеи и направления решения.

Для предварительного объект-анализа рекомендуется формулировать объединенные задачи для объектов, находящихся на верхнем иерархическом уровне компонентной модели ТС, так, чтобы в перечень "объектов/ресурсов ТС", используемых при анализе, входило 5-9 соответствующих компонентов и ресурсов.

Алгоритм объект-анализа

1. Сформулировать задачу в виде целевой функции (результат, который нам нужен)

2. Определить целевой объект² - объект, с которым непосредственно связано выполнение целевой функции

3. Установить границы оперативной зоны (ОЗ): составить перечень объектов (компонентов ТС и ресурсов), потенциально взаимодействующих с целевым объектом

4. Сформулировать ограничения на изменения каждого из объектов: составить пары возможных изменений состояния каждого объекта в течение заданного оперативного времени (ОВ)³ (при этом рассматриваются только крайние предельные значения таких изменений, а промежуточные во внимание не принимаются). (Примечание: для каждого объекта может быть рассмотрено несколько предельных состояний - в зависимости от конкретного рассматриваемого параметра: температура, размер, подвижность и т.д.)

5. Для каждого выбранного объекта ТС рассмотреть возможное влияние его "наличия-отсутствия" на целевой объект (или на выполнение целевой функции). Для этого нужно составить прямые и обратные перекрестные композиции (условно) "основного" (целевого) и "переменного" объекта:

а) объект целевой функции должен быть (есть в наличии) - не должен быть (нет в наличии)

б) объект ТС должен быть (есть в наличии) - не должен быть (нет в наличии)

Диаграмма, иллюстрирующая правило составления композиций влияния "наличия-отсутствия" какого-либо объекта/ресурса ТС на целевой объект, представлена на Рисунке 1.

6. На основе составленных пар композиций сформулировать прямые и обратные объединенные задачи по форме: "Как сделать так, чтобы..."

а) как сделать так, чтобы целевой объект "был", когда "есть" объект/ресурс ТС, и целевого объекта "не было", когда "нет" объекта/ресурса ТС.

б) как сделать так, чтобы целевой объект "был", когда "нет" объекта/ресурса ТС, и целевого объекта "не было", когда "есть" объект/ресурс ТС⁴.

(пример формулирования объединенных задач - см. в Примере ниже)

Рис. 1. Составление композиций влияния "наличия-отсутствия" какого-либо объекта/ресурса ТС на целевой объект

7. Составить пары уточненных задач: заменить (там, где возможно) в формулировках задач "был" - "не был", на уточненные формулировки с учетом установленных в п. 4 предельных изменений состояния каждого объекта (н-р, "был" может меняться на "перемещался"; "не был" может меняться на "оставался на месте")

8. Определить идеи и направления решения сформулированных задач

(при необходимости можно откорректировать поставленную задачу и перейти на шаг (1))

9. На основании идей подготовить запросы для ФОП, для патентного поиска, для анализа указателя физэффектов и т.д.

10. Сформулировать возможные вторичные задачи, требующие решения

11. Оформить предварительные концепции решения поставленной задачи

Фрагмент объект-анализа задачи со спичкой (см. выше)

Основные объекты: Нужная_Спичка, Метка (что-то, что позволит идентифицировать Нужную_Спичку), Спички (n штук), Коробок, Поверхность (н-р, стол, на котором должна оказаться Нужная_Спичка), Воздух (окружающая среда), Манипулятор (тот, кому нужна именно эта Спичка?)

Целевая функция: Нужная_Спичка (быстро) отделяется от других спичек

Целевой объект: Нужная_Спичка.

Объекты, изменяемые в задаче (переменные факторы) - возможные ресурсы: [с указанием возможных "предельных" состояний этих объектов]

Компоненты ТС:

1) Нужная_Спичка (вместе (с другими спичками) - отдельно)

2) Метка (есть - нет)

3) Спички (есть - нет)

4) Коробок (есть - нет, открыт - закрыт)

5) Поверхность (есть - нет)

6) Манипулятор (тот или то, что проделывает операции с коробком) (есть - нет)

Основные ресурсы:

1) Дерево (спички, коробок) (есть - нет, горит - не горит)

2) Огонь (спички могут гореть) (есть - нет, греет - не греет)

3) Воздух (окружающая среда) (есть - нет)

Фрагмент объект-анализа для задачи со спичкой (для двух объектов: "поверхность" и "воздух") представлен в Таблице 1.

Таблица 1. Фрагмент объект-анализа (задача со спичкой)

Примечание

Объект-анализ может быть достаточно просто компьютеризирован в виде программной оболочки, в которой "на входе" указывается перечень определенных компонентов ТС и ресурсов, целевой объект, предельные состояния всех объектов; а на выходе получаются формулировки задач для обдумывания и решения.

Трудность может заключаться только в обеспечении грамотности формулировок объединенных задач на русском языке (возможно, на английском языке получить грамотные формулировки будет проще)