Dwie stacje WRE spięte w sieć, są w stanie namierzyć z dużą dokładnością dowolnę emisje elektromagnetyczną i podać jej lokalizacje . I to nawet bardzo krótką emisje (pakiet impulsów) .
Nie od dziś kolosalne znaczenie miała "cisza radiowa".
Dwie stacje WRE spięte w sieć, są w stanie namierzyć z dużą dokładnością dowolnę emisje elektromagnetyczną i podać jej lokalizacje . I to nawet bardzo krótką emisje (pakiet impulsów) .
No i?
Penetracja rynku (fuj) sieci GSM przekroczyła w Polsce 100%, co jak mi powiedziano w nowomowie marketingowej znaczy że mamy więcej aktywnych kart SIM niz ludzi w kraju, wliczając niemowlęta.
Chyba jasne że wychodzenie z emisją w legalne częstotliwości taktyczne tj 30-88 MHz jest równoznaczne z wywieszaniem znaku "tutaj jestem i jestem żołnierzem".
Z drugiej strony - a jednak tak się robi.
Być może należało by to zmienić, byc może niekoniecznie, ale to temat jest szeroki głęboki i długi, i nadałby się na osobny wątek.
(Po wydzieleniu takiego wątku mundurowi nabiora wody w usta)
Na razie zakłada się że będziemy we wojnę rozmawiać przez radio, że będziemy rozmawiać w częstotliwościach z gory wszystkim znanych, stosując jedynie (też znane) sposoby utrudniania wykrywania jak np. hopping, i będziemy sobie udawać że nas nie złapią.
Może przy takim udawaniu zostańmy, bo inaczej jeszcze dojdziemy do wniosków że łączność powinna się opierać na gońcach...
_________________ Toast wódczany o postaci dialogu.
Zasłyszane na dniach.
:
- Ruskij wojennyj korabl?
- Do dna!
Dołączył: 13 Kwi 2010 Posty: 821 Skąd: Daleka Północ
Wysłany: Sob 17 Paź, 2015
Co do przekazywania informacji pomiędzy różnymi szczeblami jest jeszcze jedna rzecz. Podział na komunikację pomiędzy:
a) maszyna - maszyna
b) człowiek - maszyna
c) człowiek - człowiek
I tak dla przykładu akustyczny system wykrywania strzelców zamontowany na BWP może automatycznie przesłać potencjalną pozycję do celowniczego w BWP. Ale można zastanowić się nad sensownością przesyłania takich danych np. do pojedynczego żołnierza. I idąc dalej można tą informację wysłać na "wojskowego smartphona" automatycznie. Tyle że to w jakimś tam stopniu może dekoncentrować żołnierza, bo jak co chwila będzie dostawał "MMS-a z pozycją na mapię" to po prostu z czasem będzie je ignorował. To przypadek kategorii b). Informacje tą może podać również człowiek kanałem głosowym (kategoria c)) co jest bardziej przyswajalne w trakcie walki, ale może absorbować to żołnierza z BWP, który przekazuje tą informację dalej. To mniej więcej to na co można sobie pozwolić na chwilę obecną. Co prawda można sobie wyobrazić, że syntezator mowy przekazuje komunikaty głosowo, ale tu poda raczej pozycję geograficzną a nie bardziej opisową bardziej strawną dla użytkownika. Dodatkowo takie rozwiązanie nie zapewnia interakcji jak np. powtórzenia komunikatu.
Wydaje mi się, że należałoby również spojrzeć na BMS i wymianę informacji w takim aspekcie jak podział na to czy nadawcą/odbiorcą jest sprzęt czy człowiek.
można tą informację wysłać na "wojskowego smartphona" automatycznie. Tyle że to w jakimś tam stopniu może dekoncentrować żołnierza, bo jak co chwila będzie dostawał "MMS-a z pozycją na mapię" to po prostu z czasem będzie je ignorował. To przypadek kategorii b). Informacje tą może podać również człowiek kanałem głosowym (kategoria c)) co jest bardziej przyswajalne w trakcie walki, ale może absorbować to żołnierza z BWP, który przekazuje tą informację dalej. To mniej więcej to na co można sobie pozwolić na chwilę obecną.
Ja powiedziałbym tak:
Wielu tutaj wyraziło podobne wątpliwości do Twoich.
Że jak tak dużo można, to będzie tendencja żeby przedobrzyć.
Przeciąży się biegającego z karabinkiem po pierwsze informacjami które do niego docierają, po drugie zbieraniem informacji których się od niego wymaga by je potem bezzwłocznie powprowadzał, po trzecie przeciąży się go wymaganiami na temat serwisowania tego co na sobie nosi, w tym ustawień programów które będzie musiał co i raz dostosowywać do sytuacji.
Jako facet utrzymujący się od lat z programowania mogę tylko rozłożyć ręce. Wojskowi dostaną od programistów to co chcą.
Zostanie to im dostarczone najmniejszym możliwym wysiłkiem.
Wojskowi musieliby po pierwsze dobrze wiedzieć co mają chcieć, po drugie umieć sensownie a nie naodczepnego odpowiadać na setki pytań szczegółowych pojawiających się programistom podczas implementacji, po trzecie musieliby umieć odebrać produkt (co jest osobną sztuką), dalej miec plan jak go testować w warunkach zbliżonych do realnych, i na koniec realistycznie podejść do faktu że od pierwszej wersji NIC nie zadziała również z tego powodu że założenia okazują się dodupne, i wykazywać zrozumienie dla potrzeby wielokrotnego "rafinowania" tego produktu.
To samo się nie zrobi.
Moje osobiste doświadczenia na lini współpracy programiści-żołnierze są skromne, bo z programów które współtworzyłem dla swoich chlebodawców jak pamiętam jedynie jeden taki biznes który dotyczył sprzedaży specjalnie dostosowanego oprogramowania dla wojsk. (nie był to program żołnierzoprzyszłościowy)
Doświadczenia te nie napawają optymizmem.
Były to siły zbrojne Kanady.
Wspołpraca trwała latami.
Skończyła się po tych latach pozrywaniem kontraktów.
Jak nam też powiedziano prowadzący sprawy po stronie kanadyjskiej major został zdegradowany.
Tak więc sprawy jak najbardziej mogą pójść źle.
_________________ Toast wódczany o postaci dialogu.
Zasłyszane na dniach.
:
- Ruskij wojennyj korabl?
- Do dna!
Pomógł: 2 razy Wiek: 39 Dołączył: 28 Maj 2005 Posty: 5037 Skąd: Wrocław
Wysłany: Sob 17 Paź, 2015
michqq napisał/a:
Jako facet utrzymujący się od lat z programowania mogę tylko rozłożyć ręce. Wojskowi dostaną od programistów to co chcą.
Zostanie to im dostarczone najmniejszym możliwym wysiłkiem.
Ale oni sami nie wiedzą czego chcą, nikt tego chyba nie wie.
Jako facet utrzymujący się od lat z programowania mogę tylko rozłożyć ręce. Wojskowi dostaną od programistów to co chcą.
Zostanie to im dostarczone najmniejszym możliwym wysiłkiem.
Ale oni sami nie wiedzą czego chcą, nikt tego chyba nie wie.
Tym większa szansa że w pierwszej iteracji nie będzie działać i że posłuży ona głównie do dojścia "czego właściwie chcemy".
Gdybym miał decydować na poziomie "strategii" (heh...) to powiedziałbym że najlepszym podejściem byłoby nastawienie się na kilkukrotne "szybkie prototypowanie".
A więc nastawić się CELOWO na kilka iteracji "na szybko" robionych prowizorek, tak sprzętu jak i oprogramowania, na podstawie analizy których to prowizorek dopiero nauczymy się czego właściwie chcemy a czego nie chcemy.
I wtedy zrobić wymagania docelowe.
Natomiast usiłowanie zrobienia od razu od pierwszego podejścia tego produktu docelowego ma duże szanse zakończyć się klęską.
Żeby trafiać do celu należy najpierw "zmarnować" kilka nabojów na wstrzelanie się i poustawianie celownika.
Tutaj wygląda to podobnie.
Oczywiście rozumiem że dla wojska jest to trudne z wielu powodów.
Należałoby zacząć od przetargu na... zrobienie szkolenia dla personelu wojskowego na temat zamawiania oprogramowania. (!)
Należałoby "zamrozić" personel pracujący nad tematem na kilka lat na tych samych stanowiskach.
Itede itepe.
_________________ Toast wódczany o postaci dialogu.
Zasłyszane na dniach.
:
- Ruskij wojennyj korabl?
- Do dna!
Moje osobiste doświadczenia na lini współpracy programiści-żołnierze są skromne, bo z programów które współtworzyłem dla swoich chlebodawców jak pamiętam jedynie jeden taki biznes który dotyczył sprzedaży specjalnie dostosowanego oprogramowania dla wojsk. (nie był to program żołnierzoprzyszłościowy)
Doświadczenia te nie napawają optymizmem.
Były to siły zbrojne Kanady.
Wspołpraca trwała latami.
Skończyła się po tych latach pozrywaniem kontraktów.
Jak nam też powiedziano prowadzący sprawy po stronie kanadyjskiej major został zdegradowany.
Wbrew pozorom to bardzo pozytywne. Ktoś odpowiedział za bałagan.
_________________ Tylko umarli widzieli koniec wojny. Platon
Pomógł: 43 razy Dołączył: 05 Sie 2005 Posty: 4649 Skąd: Z innej bajki
Wysłany: Sob 17 Paź, 2015
Arrakis napisał/a:
jakie informacje (na jakim szczeblu) chciałbyś przesyłać?
Myślę że z dołu do góry:
Po pierwsze chciałbym aby zobrazowanie na danym szczeblu było na mapie znakiem dwa szczeble niżej i jak kliknę w znak to ukazuje mi się tabelka z informacją: stan ilościowy sił i środków paliwa, środków walki aktywnych, itp, decydujące o zdolności bojowej danego szczebla - nie dotyczy zestawu indywidualnego. W zestawie indywidualnym żadnych diód, światełek, itp cyrków na zewnątrz - dioda świecąca w nocy w lesie to nie jest normalne zdarzenie. Tablety smartfony i inne cuda z ekranem - żadnych bajerów dwa kolory oba tzw. zimne by ograniczyć/utrudnić widzialność takiego z odległości większej niż 1 - 2 m.
System indywidualny powinien automatycznie przełączać się na drugie źródło zasilania i że pierwsze trzeba naładować i dawać informację że pierwsze jest wyczerpane. Jeżeli żołnierz nie naładuje w między czasie pierwszego źródła to żołnierz powinien dostać informację o wyczerpaniu 50% drugiego źródła i przypomnienie że pierwsze puste.
Powinien umożliwiać automatyczne obliczenie u przełożonego położenia celu jak dwóch żołnierzy wymierzy w cel karabinek i naciśnie stosowny przycisk np cel,
Od żołnierza w górę (czytaj dowódcy drużyny) automatycznie powinno wychodzić:
1. podstawowe dane monitorowania życia: puls, ciśnienie krwi, oddech na ekranie u dowódcy powinna być info na zasadzie 1 lub O - parametry w normie lub nie - zdrowy nie zdrowy. żyje nie żyje i kto (nr nieśmiertelnika i specjalność). Przy czym transmisja powinna się odbywać w momencie gdy któryś z parametrów schodzi lub wzrasta ponad normę. Od dowódcy dr do dcy plutonu i do góry powinno pójść już uogólnione - cyferki ilu jest w walce. Na każdym poziomie system musi pokazywać dane uogólnione ale powinna być możliwość sprawdzenia ilu jakich specjalności mamy w walce a ilu i jakich specjalności i w którym module szczebel niżej brakuje (u dcy brygady powinno być wiadomo ilu jest i ilu brakuje w poszczególnych batalionach, u dcy batalionu powinno być wiadomo ilu brakuje w poszczególnych kompaniach, a u dcy kompanii ilu w plutonach, itd.);
2 dane o sprawności technicznej jego systemu - krótka paczka impulsów pokazująca działam;
3 położenie żołnierza - do dcy dr, wyżej powinien system uogólniać (grupować żołnierzy w drużyny, drużyny w plutony plutony w kompanie, itg) już znakiem taktycznym i przekazywać do góry;
opcjonalnie po wymuszeniu zdarzenia przez żołnierza:
położenie namierzonego celu (opisywanego sms lub głosem) a dopiero na poziomie dowódcy kompanii udokładniane i dalej do góry idzie jako znak z wypełnionymi stosownymi polami wg AAP-6)
krótkie informacje np, sms do 32 czy 64 czy 128 znaków
zdjęcie obiektu, szkicu, mapy - po prostu screen shot i to obrazowany w jakiejś mało zaciemniającej formie (mały kwadracik na mapie, który i dopiero po kliknięciu rozwijany jest w fotkę, pamiętając że ten screen shot to nie tylko w świetle widzialnym ale w podczerwieni też bo wojna zazwyczaj w nocy teraz się toczy.
Zdalnie wymuszane z góry bez wiedzy żołnierza- widok video - powinno być ograniczenie do kilku takich transmisji jednocześnie by ograniczyć zapędy dców do permanentnej kontroli poszczególnych żołnierzy i zapychania w ten sposób łączy a z kolei żeby można było prowadzić rekonesans bez jechania do dowódcy kompanii czy plutonu.
Moc takiej transmisji od żołnierza powinna być na tyle mocna/słaba by zasięg siania nie przekraczał odległości 100m, Bo ile od TO odejdzie żołnierz? Ale powinno być też urządzenie przenośne (wynośne z TO), które w sytuacji gdy żołnierze z różnych względów działają bez TO albo będzie konieczność poleźć dużo dalej od TO jak te 100m będzie mogło odwalać robotę przekaźnika danych do góry za terminal w TO.
Powinny w systemie zostać zformatowane wszelkie meldunki i rozkazy - tzw. formatki. Zero dowolności - potrzeba nowy administrator systemu wstrzeliwuje do niego nowy format a w reszcie uaktualnia się z automatu. Od szczebla kompanii powinna być możliwość ręcznego wkładania danych na mapy i formatek.
Do dołu powinny iść rozkazy (tekst i grafika), informacje na mapy, smsy podobnie jak w sytuacji do góry ograniczone co do ilości znaków. Ale do dcy plutonu może drużyny i to na ekran w wozie a do dcy info że coś przyszło ze stosownym priorytetem by wiedział czy ma natychmiast zasuwać do transportera by czytać czy może sobie odpuścić na 1h to czytanie.
System powinien automatycznie rozróżniać swój - obcy. Powinien np. żołnierzowi dostarczać informacji, że patrzy poza sektor ognia (żeby nie kombinował z kijami itp. w nocy jak nie strzelać poza wyznaczony sektor odpowiedzialności).
I na pewno powinien dawać możliwość gadania głosem przez rdst na każdym szczeblu.
Największym wyzwaniem według mnie na dole byłoby zautomatyzowanie procesu tzw. kierowania ogniem. Kto choć raz w życiu widział kierowanie ogniem batalionu czołgów czy piechoty w obronie czy natarciu zrozumie jak ogromne to wyzwanie by ogarnąć ten bajzel. A kierowanie walką brygady w obronie czy dywizji w obronie albo obu w natarciu? Giełda przy tym to oaza spokoju. Im wyżej tych wymagań przesyłu jest więcej,
Choćby profil dna rzeki na żądanie dowódcy kompanii. Na szczeblu brygady i batalionu powinien umożliwiać automatyczną ocenę terenu. Nie da się w jednym poście opisać systemu walki od żołnierza do brygady tyle tego jest. To trzebaby walnąć doktorat. Konieczne byłoby opracowanie map procesów (rozpisanych na drobne) takich jak planowanie, organizowanie działań bojowych, informowanie o sytuacji bojowej, wzywanie wsparcia z pola walki, wzywanie medevac, zaopatrywanie logistyczne. To jest kosmos w brygadzie i moloch.
michqq napisał/a:
Gecko, twoje spostrzeżenia są słuszne, czyta się to ciekawie i kiwając głową, jednak czytając je cały czas miałem w głowie fakt, że znaczny procent żołnierzy biega dziś po polu walki z radiostacjami plecakowymi oraz z osobistymi radiotelefonami, niektórzy z nich mając też dyndające kableki, w sensie nagłowne zestawy mikrofonowo-słuchawkowe i/lub przewód z PTT.
Załóż maskę pgaz a dowiesz się, że latanie w niej i urządzeniu nagłownym (takim jakie jest w TRC) jest niemożliwe - albo maska traci szczelność (mikrofon wewnątrz albo po drugiej stronie nikt Cię nie zrozumie (mikrofon na zewnątrz). Tak więc dla potrzeb tego sytemu potrzeba nowej maski pgaz z wbudowanymi mikrofonem (bo maska nie zakrywa ucha więc słuchawka może być normalna). Na dziś w terenie skażonym generalnie można spokojnie postawić tezę, że łączność maja tylko Ci co są wewnątrz szczelnych kabin pojazdów reszta działa na głos. Spróbuj w dzisiejszych realiach pogadać w namiocie z chloropikryną przez radiostację w urządzeniu nagłownym. Albo poczujesz o co chodzi ze szczelnością maski pgaz albo za chiny nie dogadasz się z drugą stroną. Bo jakiś osiołek projektowy zamienił laryngofony na mikrofon w urządzeniu nagłownym.
http://www.defence24.pl/2...row-radiostacji zdjęcie na samym dole. W tym wydaniu co na zdjęciu albo maska albo łączność.
Podobnie ma się sprawa z resetowaniem urządzeń. Dziś masz w sumie radiostację na pluton a tu ma być przy 100% żołnierzy. Skala. Nawet przy małej skali (rdst na pl) i restrykcyjnych procedurach jest ryzyko, że ktoś (czy radiotelefonista sam czy ktoś z żołnierzy obok jak radiotel zginie) nie zdąży zresetować ustawień, Ale przy nasyceniu systemem 100% żołnierzy to masz niemal pewne że na pobojowisku zostanie kilka kilkanaście ciał z aktywnym systemem.
Pozdrawiam
A Mi do szczęścia wystarczyłoby :
- położenie sił własnych w czasie rzeczywistym
- położenie przeciwnika w czasie rzeczywistym
- dane topograficzne z zobrazowaniem jak mapa i zdjęcia terenu wraz z dokładnymi koordynatami co najmniej 5-punktowymi ( w sumie 10).
- możliwość aktualizacji danych i przesyłania informacji szczegółowych według procedur ( meldunek doraźny, meldunek CAS, meldunek MEDEVAC, meldunek o wsparcie ogniowe itp.)
Wszystko poza tym tylko niepotrzebnie komplikuje i zaśmieca system. Być może dlatego ciągle czekamy na coś co jest już oczywistą potrzebą na polu walki
_________________ Nihil est in intellectu, quod non fuerit antea in sensu. J.Locke XVII w.
Nisi ipse intellectum. Leibnitz XVIII w.
A Mi do szczęścia wystarczyłoby :
- położenie sił własnych w czasie rzeczywistym
- położenie przeciwnika w czasie rzeczywistym
To drugie jest trudne.
Ja patrzę pod kątem programisty, przepraszam, i chciałbym Ci od razu powiedzieć że programista który by tutaj słuchał podniósłby paluszek do góry i pytał.
Bo zdajemy sobie sprawę, że przeciwnik usiłuje stosować skryty manewr oraz maskowanie i pozorację, a nasze rozpoznanie usiłuje identyfikować i lokalizowac technikę i personel przeciwnika, które to działania są sobie przeciwne.
W praktyce jest to trudne, żeby zwizualizowac położenie personelu i techniki przeciwnika.
Przykład pierwszy:
Nasi żołnierzo obserwują skraj lasu. Widać przecinkę w lesie. Nagle w tej przecince pojawia się TO przeciwnika który defiluje przed naszymi i znika.
Co powinno się zwizualizować. No bo tak:
Dokładnego położenia TO nie znamy, bo wlazł na powrót w las. Tak więc żadnego prostokącika punktowo nie naniesiemy na mapę. Ale informację o zgrubnym położeniu TO przeciwnika mamy, i należałoby ją jakoś przechować i jakoś wizualizować przecież.
To nie koniec jednak.
Minutę później inna grupa piechoty obserwująca ten sam las ale kawałek dalej zobaczyła że im TO mignął w innej przecince.
Co robimy. Możliwości są dwie, albo mamy do czynienia z tym samym TO, i wtedy z mapy/bazy danych wykreślamy ta pierwszą obserwację zastępując ją tą nową.
Albo mamy do czynienia z innym TO i pasowałoby w bazie danych i na mapie mieć obie obserwacje, obu TO. Jak to interpretować, jakie kryteria.
Przykład drugi:
Żadki las. Nie nad nim ale nieco na północ od niego przelatuje nasz bezpilotowiec rozpoznania. Liczy w podczerwieni źródła ciepła, dwadzieścia, jasne że sa to silniki pojazdów skrytych w zagajniku.
Minute później drugi bezpilotowiec przelatuje, tym razem nieco na południe od zagajnika. Liczy źródła ciepła, tym razem dwadzieścia pięc.
Pytanie:
Ile w zagajniku jest pojazdów?
No tak, heh, minimum to dwadzieścia pięc, a maksimum to trudno powiedzieć. Należałoby porównać zdjęcie zrobione pod kątem „z północy” ze zdjęciem zrobionym pod kątem „z południa”, wziąć pod uwagę różnicę czasu o minutę, i wydedukować które pojazdy na tych zdjęciach to te same są a które nie.
To są problemy z tylko tych co mi przychodzi do głowy na szybko.
Wykrywanie położenia własnego personelu jest względnie proste, wizualizacja ich na mapie jest względnie prosta choć nie zawsze trywialna (np. nasza kompania broni wielopiętrowego budynku...) ale pokazywanie gdzie jest przeciwnik to sprawa trudna i jak się wydaje zawsze będzie realizowana w sposób zgrubny i pełen przypuszczeń.
_________________ Toast wódczany o postaci dialogu.
Zasłyszane na dniach.
:
- Ruskij wojennyj korabl?
- Do dna!
Przede wszystkim trzeba pokazać, które informacje są pewne, a które nie. Żeby ktoś nie pomyślał, że skoro jest 15 prostokącików na ekranie, to na pewno nie ma 100 tuż obok, których nie zauważono.
Może to śmiesznie brzmi, ale do wizualizacji bym zastosował patent z gier rts, tzw. "fog of war", czyli jednostki i teren, które były wcześniej widziane, ale od tamtej pory nie wiadomo, co się z nimi stało - są pokazywane jako wyszarzone "duchy". Wtedy wiadomo, że fragmenty mapy, które są w pełnym kolorze - są 100% pewne, a im bardziej wyszarzony fragment - tym mniej pewny. I teren, na którym nie mamy zwiadu - staje się na wyświetlaczach tym bardzziej szary, im więcej czasu minęło, od ostatniego razu, kiedy ktoś od nas go widział.
Coś takiego (oczywiście skala i perspektywa byłaby inna):
Do tego można dać pod mapką suwak z czasem, żeby dowódca mógł sobie przewinąć sytuację do konkretnego momentu w przeszłości, a na suwaku zaznaczyć kropkami momenty, kiedy był kontakt z wrogiem, i kiedy przychodziły raporty zwiadu, żeby dało się później sprawdzić co dokładnie widzieli i wyciągnąć wnioski samemu.
Ale to oczywiście tylko pomysł - trzeba by zrobić prototyp i przetestować, czy się sprawdza.
michqq
Wiem że proste rzeczy są trudne więc to problem dla twórców systemu.
Przykład I odp : żołnierze którzy wykryli oznaczają na swoich BMSie przybliżone położenie przeciwnika za pomocą NATO znaków które po oznaczeniu są dostępne dla wszystkich innych ( jest tam też czas jego wykrycia i gridy). Tamci żołnierze robią to samo i wystarczy na początek.
Przykład II odp : Każdy bezpilotowiec przesyła dane co do wykrytych celi i są One oznaczane przez kontrolerów znakiem ogólnym np. batalionu zmech ( siła większa niż kompania, mniejsza niż pułk) i to wystarczy. Jeżeli dany rejon był kontrolowany kilka razy to personel decyduje które dane są najświeższe tak by nie zaśmiecać systemu ( w zakładce może być dostępna historia tego rejonu tak by można było prześledzić sytuację).
Myślę że to nie będzie stanowić problemu. Trzeba zaznaczać w jakichś sposób iż cel/ obiekt jest obserwowany nadal lub nie ( kolory, przerywana linie, miganie?). Istotą informacji dla wojsk jest że o tej godzinie w tym rejonie dostrzeżono aktywność wroga co zmusza np. do zwiększenia uwagi na tym kierunku itp. dane szczegółowe pójdą meldunkiem odnośnie wykrycia celu. Przyjmujemy zasadę że pozostaje na mapie położenie potwierdzonego celu widzianego ostatnio jeżeli kilka meldunków dotyczy tego samego. I tutaj widzę problem by tego np. TO nie meldowała cała kompania a wybrany jeden pojazd itp. To wymagać będzie dyscypliny lub ograniczenia użytkowników systemu no ale to wyjdzie w praniu. Może też tak być iż decyzję o położeniu wroga podejmować będzie TOC który w danym rejonie zbiera dane ( np. szczebla batalionowego). Kwestia do przemyślenia.
_________________ Nihil est in intellectu, quod non fuerit antea in sensu. J.Locke XVII w.
Nisi ipse intellectum. Leibnitz XVIII w.
Pomógł: 43 razy Dołączył: 05 Sie 2005 Posty: 4649 Skąd: Z innej bajki
Wysłany: Pon 19 Paź, 2015
Panowie chcecie odkrywać odkryte. APP-6 Zbiór znaków wojskowych jasno precyzuje jak wizualizować jednostki własne, obce, neutralne i o nieokreślonej przynależności. Precyzuje również jak wizualizować niepotwierdzone informacje o jednostkach i to działa w wielu armiach. Nawet znaki są zwymiarowane w znakach alfanumerycznych. Jednak zbiór znaków nie może być zamknięty by można było wprowadzać nowe znaki. Zresztą lepiej - gorzej ale w PGO jakoś to jest obrazowane.
Są też stosowne instrukcje rozpoznawcze, które precyzują jak uogólniać dane z rozpoznania wzrokowego ( tv, rlok, termowizyjnego, itp.). Tam jest zapisane że jak w terenie widzisz x czołgów to znaczy że w rejonie jest taki to a taki pododdział pancerny. Tak więc zamiast otwierać otwarte drzwi to lepiej zastosować to co już wymyślono.
Po, raz któryś powtórzę bez przerobienia procedur, zasad, instrukcji na mapy procesów nie da się opracować dobrych algorytmów do działania systemów informatycznych. A ich "myślenie" jest tak szerokie i ograniczone zarazem jak dobrze są opracowane algorytmy ukryte w oprogramowaniu. Pytanie kto jest w stanie opracować takie mapy procesów w armii?
Pozdrawiam
Pomógł: 43 razy Dołączył: 05 Sie 2005 Posty: 4649 Skąd: Z innej bajki
Wysłany: Pon 19 Paź, 2015
A jak chcesz to zrobić? Skoro cywile (nawet na tym forum w tym wątku to stwierdzono) twierdzą, że wojskowi to matoły natomiast wojskowi twierdzą, że cywile nie mają pojęcia o walce i procddurach. I obie grupy zamiast to jakoś połączyć to sobie nawzajem udowadniają, że druga strona nic nie umie, Zamiast skupiać się na swoich umiejętnościach to szukają wad u drugiej strony. Armia nie za bardzo czuje jak dużo może chcieć i dlatego nie wie czego chce a cywile nie potrafią pokazać przekonywująco co można bo nie wiedzą co jest ważne walce. Na to nakłada się bylejakość i degrengolada rzetelnej wiedzy wojskowego rzemiosła u żołnierzy i mini-max cywili (minimum wysiłku maximum zysku). W takim układzie powstanie BMS z prawdziwego zdarzenia dostosowanego do potrzeb pola walki graniczy z cudem a może nawet i przekracza to pojęcie. Jeżeli tak pójdzie dalej to zakończy się "paciorkami i lusterkami" dla ciemnego zielonego luda od wielka cywilna przyjaciela.
Pozdrawiam
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Możesz głosować w ankietach Nie możesz załączać plików na tym forum Nie możesz ściągać załączników na tym forum
REGULAMIN i FAQ
Szukaj
Użytkownicy
Grupy
Rejestracja
Zaloguj
Galeria
Download
