PROBLEMI SOGGETTIVI DELL’APPLICAZIONE DELLA MODELLISTICA MATEMATICA DELLE OPERAZIONI MILITARY

In condizioni moderne, l’area prioritaria per la riforma delle forze armate della Federazione Russa è quella di aumentare l’efficacia del loro uso, anche attraverso l’automazione del controllo delle truppe (forze). Per automazione del comando e controllo delle truppe (forze) intendiamo il processo di equipaggiamento di quartier generale, posti di comando e combattimento di complessi con computer elettronici e il loro utilizzo nel lavoro degli organi di comando e controllo.

La componente intellettuale del complesso di strumenti di automazione per il sistema di comando e controllo automatizzato (ASUV) è un software che è diviso in generale, a livello di sistema e speciale. Software speciale (SPO) ACCS è costituito da calcoli, problemi di informazione e modelli matematici. Questi ultimi svolgono un ruolo significativo nella pianificazione delle operazioni (operazioni di combattimento) e nel comando e controllo delle truppe (forze), fornendo previsioni sullo sviluppo della situazione e una valutazione comparativa dell’efficacia delle decisioni prese.

L’articolo “Modellistica del confronto armato: prospettive di sviluppo” ha considerato una serie di aspetti importanti dell’applicazione della modellistica matematica negli affari militari. Ma i fattori soggettivi “dietro le quinte” sono rimasti, sebbene in pratica abbiano un impatto significativo sull’uso della modellistica matematica nel processo di organizzazione delle operazioni (operazioni militari). Le ragioni soggettive per l’uso limitato della modellistica matematica nel lavoro pratico del quartier generale non sono state adeguatamente affrontate nelle pubblicazioni successive relative alla modellistica matematica. Quindi, nell’articolo “Problemi di automazione del supporto decisionale intellettuale da parte di comandanti di armi combinate in un collegamento tattico”, si nota che i modelli matematici dovrebbero essere una componente essenziale di un ASUV, ma non hanno trovato ampia applicazione nel processo decisionale per combatterlo e controllarlo. Perché questo non è stato specificato. Consideriamo principalmente le carenze dei modelli esistenti e fattori tecnologici oggettivi che impediscono l’uso della modellistica matematica. Ragioni soggettive sono menzionate di passaggio.

Però, acampo militare, caratterizzato da un feroce confronto e un’alta responsabilità personale del decisore, la presenza di un fattore soggettivo non è solo un fenomeno inevitabile, ma anche naturale. In condizioni di informazione incompleta, i comandanti esperti (superiori) sono in grado di formulare le giuste decisioni a livello intuitivo. Inoltre, di solito procedono dalle loro idee soggettive sull’importanza di vari criteri per l’ottimalità e l’efficacia delle possibili alternative alle decisioni. È questo che spesso provoca il rifiuto soggettivo dei risultati della modellistica matematica, che alla fine può portare a gravi errori nella pianificazione e nel controllo del combattimento [1-4].

Pertanto, la presenza di fattori soggettivi che limitano l’uso della modellistica matematica negli affari militari è un fatto reale che richiede riflessione e l’adozione di misure appropriate.

Cosa determina esattamente i casi di rifiuto soggettivo dell’uso della modellistica matematica da parte dei funzionari degli organi di comando e controllo militari? Ci sono molte ragioni e compaiono sia nelle fasi di sviluppo che nella fase di utilizzo dei modelli matematici.

Le ragioni principali del rifiuto di qualsiasi innovazione, come assicurano gli psicologi, sono la mancanza di comprensione della sua essenza, l’ignoranza delle caratteristiche e l’incapacità di applicarla.

La procedura esistente per l’applicazione di software per sistemi di controllo automatico di sistemi di controllo automatizzato implica che l’utente ufficiale dei sistemi di controllo automatico per sistemi di controllo automatico sia a conoscenza di alcune limitazioni e ipotesi adottate nello sviluppo di software open source, i limiti di applicabilità dei modelli matematici dalla composizione del software open source. È all’interno di questi confini che vengono effettuati controlli e test sugli elementi SPO, confermandone l’operabilità e l’adeguatezza. Ciò si applica pienamente ai modelli matematici come parte integrante del software open source. Teoricamente, i funzionari OVU (autorità military) applicano le componenti SPO nella loro pratica, deve comprendere i limiti di applicabilità del modello matematico con un attento studio della documentazione operativa per i componenti del software open source. Comprendi, ricorda e fatti sempre guidare da loro. Sfortunatamente, questa situazione ideale non si realizza sempre nella pratica, prima di tutto a causa dell’imperfezione dell’organizzazione del processo di formazione dei funzionari di OVU per lavorare su strumenti di automazione.

Un altro problema è quello della condivisione della responsabilità delle decisioni tra l’utente del modello e lo sviluppatore del suo apparato matematico. Se nei sistemi tecnici la divisione della responsabilità per errori operativi tra lo sviluppatore e l’utente è prescritta nei relativi GOST [5] e regolamenti tecnici, per il software non esistono ancora tali documenti. L’alto grado di responsabilità dei funzionari OVU per i risultati delle loro attività, unito a una incerta comprensione dei limiti di applicabilità dei modelli, solleva alcune preoccupazioni tra i funzionari quando utilizzano la modellazione matematica nella pratica della pianificazione di operazioni reali (operazioni militari). Senza risolvere questo problema, è impossibile garantire il pieno utilizzo della modellistica matematica nella pratica dell’operazione OVU.

Influisce significativamente sull’implementazione della modellistica matematica nella pratica OVU irrazionalità del layout delle interfacce di modelli matematici creati dall’industria. Aal momento non vi è sufficiente attenzione a questo aspetto nella progettazione del programma. La psicologia ingegneristica e l’ergonomia non aggiungono ottimismo: riguardano principalmente le modalità operative e le attrezzature del posto di lavoro dell’operatore, ma non la qualità delle interfacce del programma.

Allo stesso tempo, con lo sviluppo della tecnologia informatica, aumentando le capacità della tecnologia informatica, le persone stanno diventando sempre più il collegamento che rallenta il processo decisionale nei sistemi di controllo automatizzato. E la ragione qui è l’interfaccia del programma, che rallenta sia il processo di immissione dei dati iniziali sia l’analisi dei risultati della simulazione. Dopotutto, l’interfaccia è l’elemento principale della comunicazione dell’utente e del programma. Spesso è la comodità dell’interfaccia a determinare se l’utente accederà al programma nei momenti critici, se sarà in grado di eseguire rapidamente calcoli e analizzare i loro risultati [6-10].

È un peccato che il lavoro creativo e “pezzo-lavoro” sulla creazione di interfacce di programma e sullo sviluppo di approcci per la loro unificazione, che può essere fatto solo da uno specialista con ampi orizzonti operativi e tecnici, non si applica all’attività scientifica. Inoltre, la mancanza di approcci unificati all’implementazione dell’interfaccia di modelli matematici e problemi di calcolo delle informazioni riduce significativamente le proprietà degli utenti, rende difficile per i funzionari padroneggiare e introdurre OVU nelle loro attività.

In conformità con le linee guida, due categorie di sviluppatori prendono parte alla creazione di interfacce modello e attività dal software per i sistemi di controllo automatico per il controllo industriale: dipendenti della NRU del Ministero della Difesa, leader del supporto militare-scientifico per la creazione di sistemi di controllo automatico e sviluppatori di software nelle imprese industriali. Tutti loro sono almeno specialisti nell’uso della tecnologia informatica. Ma queste abilità possono svolgere un ruolo negativo. Lo specialista crea inconsciamente l’interfaccia del modello “per se stesso”, e non per un agente che lavora in condizioni di forte pressione temporale ed è un esperto in campo militare. E la logica del programmatore è spesso diversa dalla logica di una persona comune. Non c’è da stupirsi se scherzano sul fatto che una persona normale crede che ci siano 1000 byte in un kilobyte e che il programmatore sia sicuro che ci siano 1024 grammi in un chilogrammo. Come risultato di queste differenze, la semplicità dell’interfaccia durante lo sviluppo viene spesso sacrificata per il bene di alcune qualità e capacità aggiuntive che sembrano necessarie per il programmatore. Di conseguenza, ci sono difficoltà nel padroneggiare le interfacce di modelli e compiti da parte dei funzionari dell’OVU, riluttanza a lavorare con loro per risolvere problemi pratici.

L’impatto negativo di questo fattore può essere eliminato solo modificando l’ordine di sviluppo esistente di SMPO (matematica e software speciali), garantendo una partecipazione più stretta ail processo di sviluppo di un modello matematico per l’utente finale. Per questo, è consigliabile introdurre le fasi obbligatorie dell’operazione di prova degli elementi del software open source amodello con il coinvolgimento di funzionari dell’OVU. Sulla base dei risultati dello stage, è necessario prevedere il completamento di elementi di software open source aparti dell’organizzazione dell’interfaccia del programma. Nel campo dello sviluppo di software commerciale, il problema viene risolto utilizzando le tecnologie di progettazione di UX / DX – design, ma nella sfera militare tutto è un po ‘più complicato a causa delle limitazioni tecnologiche e delle specifiche del software [11-14].

A proposito, l’esperienza mondiale nello sviluppo del software mostra che qualsiasi tecnologia utilizzata in questo caso (a cascata, a spirale o breadboard) contiene necessariamente una fase di prototipazione, secondo i risultati del quale il software, inclusa la sua parte di interfaccia, viene finalizzato.

È anche importante atteggiamento personale di ciascun funzionario nei confronti dei risultati della modellistica matematica.Questo atteggiamento può essere espresso con diffidenza generale nei risultati ottenuti usando un apparato matematico sconosciuto e formato nel corso della “comunicazione” con i modelli. Quest’ultimo dovrebbe essere sottolineato.

Non è un segreto che a volte i funzionari OVU che non sono soddisfatti dei risultati della simulazione provano a correggerli in vari modi. Un utente (operatore) che conosce bene il modello può “giocare” con vari fattori in modo da influenzare i risultati ail lato corretto. Quando diventa un decisore, crea l’opinione che il modello possa mostrare qualsiasi risultato, ci sarebbe solo un desiderio. Questa opinione è profondamente errata e nasce dall’ignoranza delle caratteristiche della modellistica matematica. Sì, il risultato della simulazione può essere leggermente corretto modificando le condizioni iniziali per l’organizzazione delle azioni delle fazioni in guerra, appartenenti alla categoria degli incerti e scelte dall’operatore entro i limiti stabiliti. Ma per rig i risultati senza modificare i dati iniziali è impossibile, soprattutto se il modello viene utilizzato per un’analisi comparativa delle opzioni per l’utilizzo di truppe (forze), a parità di altre condizioni. I risultati stessi possono variare, ma il modello mostrerà comunque la tendenza corretta a cambiare la situazione.

Un approccio perla risoluzione di questa situazione, a nostro avviso, è la stessa - coinvolgimento di funzionari nello sviluppo dell’apparato matematico, che è previsto nell’SMPO, creato per automatizzarli attività.Ciò si riferisce principalmente alla formalizzazione del processo simulato e alla formazione di un sistema di tolleranze e restrizioni.

Coinvolgere i funzionari OVU nello sviluppo di SMPS, in particolare per descrivere l’apparato di modelli matematici, non è un modo semplice. Ciò richiede al cliente e all’industria determinati sforzi non solo di piano tecnico, ma anche organizzativo e talvolta educativo. Ma l’esperienza pratica di tale lavoro disponibile presso il 27 ° Istituto centrale di ricerca del Ministero della Difesa indica l’efficacia di questo metodo. Lo sviluppo di una serie di metodi operativi di calcolo in collaborazione con gli ufficiali dell’OVU ha dimostrato che successivamente il software che implementa l’apparato matematico creato congiuntamente viene percepito dagli ufficiali molto meglio. La conoscenza dell’apparato matematico utilizzato nel software, i limiti della sua applicabilità fornisce fiducia nei risultati della simulazione.

Pertanto, l’analisi dei fattori soggettivi che impediscono l’uso della modellistica matematica nel lavoro pratico di OVU mostra che le carenze esistenti sono sistemiche. Non dipendono dallo sviluppatore specifico del software open source e dall’approccio da lui scelto per creare il software open source per i sistemi di controllo automatico: funzionale, strutturale o di processo. Per eliminarli, è necessario cambiare l’ordine sia della creazione di modelli matematici, introducendo passaggi obbligatori per la partecipazione dei futuri utenti dei modelli nel loro sviluppo, sia della procedura per preparare i funzionari dell’OVU a lavorare con loro.

Oltretutto, vale la pena soffermarsi su un altro fattore soggettivo di sfiducia nella modellistica matematica,insorgono in casi in cui i rappresentanti del settore spesso modificano irragionevolmente modelli matematici o cercano di implementarli laddove non vi sia alcuna necessità oggettiva per questo.

L’analisi dell’esperienza straniera mostra che il più accettabile è il graduale aumento delle capacità dei modelli matematici dovuto alla loro modernizzazione senza una fondamentale alterazione del “nucleo” matematico e, naturalmente, l’uso della modellistica matematica per operazioni di pianificazione (operazioni di combattimento) solo dove è realmente necessario, dove per questo ci sono condizioni. Sfortunatamente, nel nostro paese tutto accade spesso esattamente al contrario. Il perfezionamento irragionevolmente frequente dei modelli, la diffusione della modellistica matematica nelle aree in cui non è applicabile (ad esempio al livello di “battaglione – compagnia (batteria) – plotone”), riduce soggettivamente la fiducia nel processo di applicazione dei modelli durante la pianificazione di operazioni militari e scredita l’idea stessa di modellistica matematica.

Pertanto, al fine di ridurre l’impatto negativo dei fattori soggettivi sull’uso della modellistica matematica nella pratica di OVU, è necessario aumentare le conoscenze e le competenze degli utenti di SMPO e superare la riluttanza degli sviluppatori a tenere conto delle loro esigenze (superate sotto la guida ferma del cliente dell’ASUV, con l’aiuto dell’OVU e delle organizzazioni che forniscono supporto militare-scientifico lavori).

Per fare questo, devi:

- miglioramento dello sviluppo di modelli matematici, inclusione nel processo di sviluppo delle fasi obbligatorie di prototipazione e modelli di prova in OVU; un cambiamento di atteggiamento (maggiore attenzione) nella creazione di interfacce di programma di modelli matematici dalla composizione di ASUV SMPO;

- aggiornamento dei documenti di governo che definiscono il contenuto delle fasi di sviluppo dei modelli matematici;

- ottimizzazione del processo di formazione per funzionari che utilizzano modelli matematici come parte di software open source per kit di automazione per centri di controllo.

L’attuazione di queste misure consentirà alla modellistica matematica di prendere il suo giusto posto nel processo di organizzazione delle operazioni (operazioni militari) e di comando e controllo delle truppe (forze). E, successivamente, formare un sistema unificato di modellizzazione delle operazioni militari con una chiara separazione dei ruoli e delle funzioni dei suoi partecipanti [15,16,17].

1. Vypasnyak V.I., Kalinovsky D. B., Tikhanychev O. V. Modellistica del confronto armato: prospettive di sviluppo // Pensiero militare. 2009. No. 7. pp. 12-20 (in russo).
2. Merkulov S. N., Sukhorukov Yu. S., Donskov Yu. E. Problemi automazione del supporto decisionale intelligente comandanti d’armi combinati nel legame tattico // Pensiero militare. 2009. No. 9. pp.43-53 (in russo).
3. Tikhanychev O.V. Interfacce utente nei sistemi automatizzati: problemi di sviluppo // Sistemi software e metodi computazionali. 2019. No. 2. pp. 11-22. DOI: 10.7256 / 2454-0714.2019.2.28443 (in russo).
4. Koronchik D.N. Interfacce utente di sistemi intelligenti // Cibernetica e programmazione. 2012. No 1. pp.16-22. DOI: 10.7256 / 2306-4196.2012.1.13861(in russo).
5. Lipaev V.V. Gestione dello sviluppo software. Methods, Standards, Technology. M .: Finance and Statistics, 1993 (in russo).
6. Tikhanychev O.V. Aspetti soggettivi dell’applicazione della modellistica matematica delle operazioni militari nella pratica del comando e controllo militari // Pensiero militare. 2011. No. 10. pp. 49-53 (in russo).
7. Quarterman J.S., Wilhelm S. Unix, Posix and open systems: The open standards puzzle. N.Y., Addison-Wesley Publishing; Company, 1993. 416 p.
8. Shahzad, S., Granitzer, M., Tochtermann K.: Designing User Interfaces through Ontological User Model, Proceedings of the Fourth International Conference on Computer Sciences and Convergence Information Technology ICCIT 2009, Seoul, Korea, 24-26 November 2009. pp.99-104.
9. Vichugova A. A. Fasi, metodi e mezzi per configurare i sistemi di informazione // Informatica applicata. 2015.  No. 3 (57). pp.88-99 (in russo).
10. Tregubov A.S. Sviluppo di interfacce adattive sensibili al contesto usando modelli ontologici // Cibernetica e programmazione. 2017.-No 6. pp.50-56. DOI: 10.7256 / 2306-4196.2017.6.24747 (in russo).
11. Keyno P.P., Siluyanov A.V. Sviluppo e implementazione di un interprete per il linguaggio dichiarativo per la modellazione di interfacce Web su sistemi altamente caricati // Informatica applicata. 2015. No. 1 (55). pp.55-70 (in russo).
12. Kolchugina E.A., Zavarovsky K.V. Applicazione di metodi di programmazione genetica allo sviluppo di interfacce web // Informatica applicata. 2012. N. 5 (41). pp.64-74 (in russo).
13. Strumenti di prototipazione rapida // Sito Web habr. URL: https://habr.com/post/70001 (data di accesso 13.12.2019)
14. How Human. Memory Works: Tips for UX Designers. UX Planet. URL: https://uxplanet.org (data di accesso 9.01.2020)
15. Vypasnyak V.I., Guralnik A.M., Tikhanychev O.V. Modellistica di operazioni militari: storia, stato attuale e prospettive di sviluppo // Pensiero militare. 2014. No. 7. pp. 28-37 (in russo).
16. Vypasnyak V.I., Denisov V.N., Tikhanychev O.V. La creazione di modelli matematici e problemi di progettazione per la pianificazione dell’uso di raggruppamenti interspecifici di truppe (forze) per sistemi di comando e controllo automatizzati / Enciclopedia “Storia della tecnologia informatica elettronica russa”. Mosca: Metropolitan Encyclopedia, 2017. pр. 581-585. ISBN 978-5-903989-34-8 (in russo).
17. Denisov V.N., Sayapin O.V., Tikhanychev O.V. Modellistica di operazioni militari (di combattimento): da singoli compiti e modelli a un sistema di modellamento // IV Conferenza tutta russa della RTI del sistema VKO-2016 – Casa editrice di MSTU intitolata a Bauman Mosca, 2016. – pp. 160–167 (in russo).

All articles of author «Oberst»