დაკავშირებული პროდუქტი შეიძლება დასრულებულად გამოიყურებოდეს მის გარშემო ინჟინერიის დასრულებამდე დიდი ხნით ადრე. პროტოტიპი სტაბილურია, მონაცემები ღრუბელში აღწევს, აპლიკაცია აჩვენებს სწორ მნიშვნელობებს და მოწყობილობების პირველი პარტია უკვე მომხმარებლების ხელშია. ამ ეტაპზე, ბექენდი შეიძლება ჯერ კიდევ საკმარისად მარტივი იყოს, რომ გუნდმა თითქმის ყველა მოწყობილობა ინდივიდუალურად იცოდეს. უზრუნველყოფა შესაძლებელია სკრიპტის საშუალებით, კონფიგურაციის ცვლილებების ხელით განხორციელება და თუ რამე ვერ მოხერხდა, ინჟინერს, როგორც წესი, შეუძლია პრობლემის პირდაპირ აღმოჩენა.
შემდეგ ის რეალურ სამყაროში უნდა იცხოვროს. ჩნდება აპარატურის მეორე ვერსია. ზოგიერთი მომხმარებელი კვლავ იყენებს პირველ ვერსიას. პროგრამული უზრუნველყოფის ვერსიები იწყებს განსხვავების შექმნას. სხვა მომხმარებლისთვის ან ბაზრისთვის საჭიროა ახალი კონფიგურაცია, ხოლო ძველ მოწყობილობებს კვლავ სჭირდებათ განახლებები და მხარდაჭერა.
არაფერია აუცილებლად გაფუჭებული. მოწყობილობის უკან მდგარმა პროგრამულმა უზრუნველყოფამ უბრალოდ შეიძინა საკუთარი სასიცოცხლო ციკლი.
ეს გადასვლა ადვილად შეუმჩნეველი რჩება, რადგან პროტოტიპს შეუძლია შეუფერხებლად გააგრძელოს მუშაობა. თუმცა, როგორც კი ერთი და იგივე ფიზიკური პროდუქტის რამდენიმე ვერსია თანაარსებობს, ბექენდი აღარ არის მხოლოდ აპარატურის უკან მდგომი ინფრასტრუქტურა. ის თავად პროდუქტის არქიტექტურის ნაწილი ხდება.
მოქმედი დაკავშირებული პროტოტიპი ჯერ არ არის მასშტაბირებადი პროდუქტი
პროტოტიპს მნიშვნელოვანი ამოცანა აკისრია: სისტემის სრულყოფილად მუშაობის დამტკიცება. მოწყობილობა ასრულებს თავის ძირითად ფუნქციას, პროგრამული უზრუნველყოფა უკავშირდება შიდა სისტემას, ტელემეტრია აღწევს საჭირო ადგილას, ბრძანებები ბრუნდება და მობილური ან ვებ ინტერფეისი მომხმარებელს ფუნქციონალურობას აწვდის.
რაც, როგორც წესი, არ ამტკიცებს, არის ის, თუ რამდენად კარგად უმკლავდება ერთი და იგივე სისტემა მრავალფეროვნებას.
პირველი ოცი მოწყობილობა შესაძლოა ერთი და იგივე firmware-ით იყოს აღჭურვილი, ერთი და იგივე აპარატურული ვერსიით იყოს აგებული და ერთი და იგივე ინჟინრების მიერ იყოს კონფიგურირებული. ამ ეტაპზე, ხელით რეგისტრაცია, კონფიგურაციის პირდაპირი ცვლილებები ან მცირე ონბორდინგის სკრიპტი შეიძლება სრულიად გონივრული იყოს. პროდუქტის დამტკიცებამდე საწარმოო დონის ინსტრუმენტების შექმნა შესაძლოა ნაადრევი იყოს.
მასშტაბირება პრობლემას ცვლის. მოწყობილობები ოფლაინ რეჟიმში რჩება, იცვლება, სხვადასხვა firmware-ს იყენებს და მომხმარებლის სხვადასხვა კონფიგურაციას საჭიროებს. მხარდაჭერის სამსახურმა უნდა განასხვავოს მოწყობილობა, რომელიც არასდროს ყოფილა სწორად უზრუნველყოფილი არასწორად კონფიგურირებული ან უბრალოდ მიუწვდომელი მოწყობილობისგან.
პროტოტიპის ვალი ხშირად ასე იწყება: არა ცუდი გადაწყვეტილებით, არამედ დროებითი გადაწყვეტილებით, რომელიც პროდუქტის გადასვლის შემდეგაც რჩება ძალაში. და ერთ-ერთი პირველი, რაც ამ გადასვლას თვალსაჩინო ადგილას აყენებს, თავად აპარატურაა. ახალი ვერსია უბრალოდ არ ცვლის ძველს; ის მასთან უნდა თანაარსებობდეს.
აპარატურის ყოველი განახლება პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის პრობლემას ქმნის.
ახალი აპარატურის ვერსია იშვიათად ცვლის ძველ ვერსიას. პრაქტიკაში, ორივე ვერსია რჩება ბაზარზე, ზოგჯერ წლების განმავლობაში. დაამატეთ გარდამავალი პარტია, რამდენიმე firmware-ის განშტოება და მომხმარებლისთვის სპეციფიკური კონფიგურაციები და ავტოპარკი სწრაფად გახდება უფრო მრავალფეროვანი, ვიდრე პროდუქტის ორიგინალი მოდელი გვთავაზობს.
პროგრამული უზრუნველყოფის დონეს აღარ შეუძლია ყველა ერთეულის, როგორც აბსტრაქტული „მოწყობილობის“ განხილვა. მას სჭირდება იმის ცოდნა, თუ რა შეუძლია ამ კონკრეტულ ერთეულს.
განახლებულ დაფას შეიძლება ჰქონდეს განსხვავებული სენსორი, საკომუნიკაციო მოდული ან კონტროლერი. ბრძანება, რომელიც ვალიდურია უახლესი ვერსიისთვის, შესაძლოა არ იყოს მხარდაჭერილი ადრინდელი ვერსიით. კალიბრაციის მნიშვნელობები შეიძლება შეიცვალოს. კონფიგურაციის ლიმიტები შეიძლება შეიცვალოს. ერთი თაობისთვის შესაფერისი firmware პაკეტი შეიძლება სახიფათო იყოს მეორისთვის.
ფიზიკური პროდუქტის ინჟინრები უკვე ამ გზით მუშაობენ. ორი თითქმის იდენტური კომპონენტი არ არის ურთიერთშემცვლელი, თუ მათი ვერსიები, ტოლერანტობები ან სპეციფიკაციები განსხვავდება. დაკავშირებული პროდუქტები იგივე პრობლემას ქმნის პროგრამული უზრუნველყოფის მხრივ: პლატფორმას სჭირდება საიმედო გზა იმის გასაგებად, თუ ფიზიკური პროდუქტის რომელ ვერსიას ეხება და რა წესები ვრცელდება მასზე.
განვიხილოთ პროდუქტი, რომლის პირველი ვერსია იყენებს ერთ კალიბრაციის პროცედურას, ხოლო მეორე ვერსია ნერგავს ახალ სენსორს და პარამეტრების განსხვავებულ ნაკრებს. მომხმარებლისთვის ორივე მოწყობილობა შეიძლება მაინც ერთი და იგივე პროდუქტი იყოს. პლატფორმისთვის კი - არა.
თუ ეს განსხვავებები ცალსახად არ არის წარმოდგენილი, ისინი, როგორც წესი, აპლიკაციის ლოგიკაში განსაკუთრებული შემთხვევების სახით ჟონავენ. ერთი სამუშაო პროცესი სერიული ნომრების დიაპაზონს ამოწმებს. მეორე იყენებს firmware ვერსიას, როგორც აპარატურის გენერირების პროქსის. მესამე შეიცავს გამონაკლისს, რომელიც დაემატა მას შემდეგ, რაც მხარდაჭერამ აღმოაჩინა, რომ ძველი პარტია ველზე განსხვავებულად მოქმედებდა. არცერთი ეს გამოსწორება არ გამოიყურება განსაკუთრებით საშიშად თავისთავად, მაგრამ ერთად ისინი ყველა მომავალ ცვლილებას ართულებენ მსჯელობას.
ძველი აპარატურა იშვიათად ქრება გრაფიკით. პროდუქტის გუნდები, ბუნებრივია, ყურადღებას ამახვილებენ უახლეს ვერსიაზე, მაშინ როცა მომხმარებლები ხშირად უფრო დიდხანს ინახავენ ადრინდელ ვერსიებს, ვიდრე მოსალოდნელი იყო. ამიტომ, პლატფორმას ერთდროულად რამდენიმე თაობის მხარდაჭერა უწევს, იმის ნაცვლად, რომ ვივარაუდოთ, რომ დაინსტალირებული ბაზა ოდესმე ერთ მიმდინარე მდგომარეობაზე გაერთიანდება.
როგორც კი ეს მოხდება, აპარატურის ევოლუცია და პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის მართვა განუყოფელი ხდება. პლატფორმამ არა მხოლოდ უნდა იცოდეს, სად მდებარეობს მოწყობილობა და არის თუ არა ის ონლაინ, არამედ რა არის ის, რისი გაშვება შეუძლია, როგორ უნდა იყოს კონფიგურირებული და რომელი ცვლილებების გამოყენებაა უსაფრთხო.
და სანამ ამ კითხვებზე სანდო პასუხს გასცემენ, თითოეული მოწყობილობა სისტემაში თანმიმდევრულად უნდა შევიდეს.
დებულება არის ის, სადაც ხელით ინჟინერია წყვეტს მასშტაბირებას
მცირე ზომის მოწყობილობების შემთხვევაში, უზრუნველყოფა მარტივად გამოიყურება: შექმენით მოწყობილობის ჩანაწერი, შეიყვანეთ სერიული ნომერი, გენერირეთ ავტორიზაციის მონაცემები, მიანიჭეთ მოწყობილობა მომხმარებელს, გამოიყენეთ კონფიგურაცია და გააგრძელეთ. რამდენიმე ათეული მოწყობილობისთვის, ამ ყველაფრის ხელით დამუშავება მაინც შეიძლება სწორი არჩევანი იყოს.
თუმცა, წარმოების მასშტაბზე, უზრუნველყოფა მოწყობილობის იდენტობის, ავტორიზაციის მონაცემების, საკუთრების, კონფიგურაციისა და სასიცოცხლო ციკლის მდგომარეობის გადაკვეთაზეა. დანერგვის დროს დაშვებულმა შეცდომამ შეიძლება გავლენა მოახდინოს მოწყობილობის მუშაობასა და მხარდაჭერაზე ქარხნიდან გასვლის შემდეგაც კი.
შესაძლოა, ცხრილი აღარ ემთხვეოდეს რეალურად დაინსტალირებულ მონაცემებს. ჩანაცვლებით მოწყობილობას სჭირდება სწორი მომხმარებლის ასოციაცია არასწორი იდენტიფიკაციის მემკვიდრეობით მიღების გარეშე. ქარხნული პარამეტრების აღდგენა პროცესის სხვა გზას ქმნის. ინსტალატორს შეუძლია მოწყობილობა არასწორ ანგარიშზე მიაკუთვნოს, რის შედეგადაც მხარდაჭერის სამსახურს შეუძლია დაადგინოს, ოფლაინშია თუ არა ის, არასწორად არის მოწოდებული, თუ უბრალოდ არასწორ კონფიგურაციას ატარებს.
როგორც კი ამ კითხვებზე პასუხის გასაცემად დეველოპერს რუტინულად დასჭირდება მონაცემთა ბაზის შემოწმება ან შიდა სკრიპტის გაშვება, პროცესი პროდუქტთან ერთად მასშტაბირებას წყვეტს.
დუბლირება კიდევ ერთი გამაფრთხილებელი ნიშანია. პროდუქტის თითოეული ვარიანტი იწყებს საკუთარი ინტეგრაციის სკრიპტის, კონფიგურაციის ინსტრუმენტის ან ინსტალატორის სამუშაო პროცესის შეძენას. ეს განსხვავებები შეიძლება უმნიშვნელოდ გამოიყურებოდეს, მაგრამ ძირითადი პასუხისმგებლობა იგივეა. უზრუნველყოფა გახდა მრავალჯერადი გამოყენების პლატფორმის ინფრასტრუქტურა და არა კონკრეტულ მოწყობილობაზე მიმაგრებული დაყენების დავალება.
და ეს იშვიათად არის ერთადერთი შესაძლებლობა, რომლის ხელახლა გამოყენებაც საჭიროა.
პლატფორმის ფენა უნდა გახდეს მრავალჯერადი გამოყენების ინფრასტრუქტურა.
როგორც კი რამდენიმე პროდუქტს ან აპარატურულ ვერსიას ერთი და იგივე ძირითადი მოთხოვნილებები ექნება, პროგრამული უზრუნველყოფის ზოგიერთი შესაძლებლობა წყვეტს პროდუქტზე სპეციფიკურობას. მოწყობილობის იდენტიფიკაცია, უზრუნველყოფა, დაკავშირებადობა, ტელემეტრია, პროგრამული უზრუნველყოფის მიწოდება, სასიცოცხლო ციკლის მდგომარეობა, ავტოპარკის ხილვადობა და დიაგნოსტიკა კარგი მაგალითებია. მათი ყოველი ახალი ვარიანტისთვის ხელახლა შექმნა ქმნის მეტ კოდს და მეტ ოპერაციულ გზას შესანარჩუნებლად, თავად პროდუქტის უფრო გამორჩეული გახდომის გარეშე.
გუნდები იშვიათად ცდილობენ ამ დუბლირების შექმნას. თითოეული პროდუქტის გარშემო მცირე განსხვავებები გროვდება მანამ, სანამ გუნდი არ შეინარჩუნებს იმავე საინჟინრო პასუხისმგებლობად ქცეული რამდენიმე იმპლემენტაციას.
უფრო მკაფიო საზღვარი პროდუქტის ფენის პლატფორმის ფენისგან გამოყოფაა. პროდუქტის ფენა შეიცავს ქცევას, სამუშაო პროცესებს, ინტერფეისებს, ინტეგრაციებსა და დომენის ლოგიკას, რაც კონკრეტულ მოწყობილობას ღირებულს ხდის. პლატფორმის ფენა ამუშავებს მექანიკას, რომელიც უნდა დარჩეს თანმიმდევრული აპარატურის ცვლილების მიუხედავად.
როდესაც დაკავშირებული პროდუქტები პირველი გამოშვების პერიოდს სცილდება, მოწყობილობების უზრუნველყოფა, მოწყობილობის სასიცოცხლო ციკლის მართვა, ავტოპარკის მართვა და დამხმარე ინსტრუმენტები პროექტის ერთჯერადი დეტალების ნაცვლად საერთო ინფრასტრუქტურად იქცევა. საწარმოებისთვის განკუთვნილი IoT PaaS-ს შეუძლია უზრუნველყოს მრავალჯერადი გამოყენების პლატფორმის ფენა მრავალ პროდუქტზე ან პროდუქტის ვარიანტზე, სტანდარტული მოწყობილობებისა და მონაცემების მართვის დამუშავებით მრავალჯერადი გამოყენების სამშენებლო ბლოკების მეშვეობით, ხოლო საინჟინრო გუნდები ყურადღებას ამახვილებენ აპარატურაზე, სამუშაო პროცესებსა და მომხმარებლის გამოცდილებაზე.
საერთო საფუძველს მაინც უნდა დარჩეს ადგილი პროდუქტის რეალური განსხვავებებისთვის. ახალ მოწყობილობას შეიძლება დასჭირდეს განსხვავებული მონაცემთა მოდელი, კონფიგურაციის ნაკადი, ინტეგრაცია ან მართვის ლოგიკა და ეს განსხვავებები ადვილად დასანერგი უნდა დარჩეს. მიზანი უბრალოდ ისაა, რომ თავიდან ავიცილოთ ყველა განსხვავების სხვა მოწყობილობების რეესტრში, ტელემეტრიის არხს, უზრუნველყოფის მექანიზმში ან ფლოტის მართვის ინსტრუმენტების ნაკრებში გადატანა.
პლატფორმა შესაძლოა, გუნდის მიერ პირველი პროდუქტის შექმნისას ზედნადები ხარჯის სახით გამოიყურებოდეს, ხოლო მეორე ან მესამე პროდუქტის შექმნისას - აქტივად. როგორც კი საერთო ოპერაციული მექანიკა დამკვიდრდება, ახალ ვარიანტს შეუძლია მემკვიდრეობით მიიღოს მოქმედი საფუძველი, იმის ნაცვლად, რომ მას ჰქონდეს სხვა ბექენდი, რომლის შენარჩუნებაც გუნდს პროდუქტის სიცოცხლის ბოლომდე მოუწევს.
შეინარჩუნეთ ინდივიდუალური ინჟინერია იქ, სადაც პროდუქტი რეალურად განსხვავებულია
მრავალჯერადი გამოყენების პლატფორმა არ უნდა ხდიდეს დაკავშირებულ პროდუქტებს უფრო ზოგადს. მისი ფუნქციაა იმ ნაწილებიდან განმეორებითი ინჟინერიის ამოღება, რომლებიც დიფერენციაციას არ ქმნის.
მორგებული ძალისხმევა კვლავ მოწყობილობის ქცევას, დომენ-სპეციფიკურ ლოგიკას, სამუშაო პროცესებს, მომხმარებლის გამოცდილებას, სპეციალიზებულ ინტეგრაციებს და კონკრეტული პროდუქტის ფიზიკურ სამყაროსთან ურთიერთქმედების წესს მიეკუთვნება. ეს ზუსტად ის სფეროებია, სადაც საინჟინრო არჩევანს შეუძლია ერთი პროდუქტი მნიშვნელოვნად უკეთესი გახადოს მეორეზე.
იშვიათად იმსახურებს ერთნაირ მოპყრობას მიმდებარე ოპერაციული სანტექნიკა. ერთი და იგივე მანქანის საბაზისო და სამრეწველო ვერსიებს შეიძლება დასჭირდეთ განსხვავებული სენსორები, მართვის საშუალებები და ინტერფეისები, მაგრამ მათ არ უნდა სჭირდებოდეთ მოწყობილობების იდენტიფიცირების, პროგრამული უზრუნველყოფის ვერსიების თვალყურის დევნების ან ავტოპარკის მართვის ცალკეული გზები.
მირჩევნია, ინჟინრები ამ დროს პროდუქტის ქცევის დახვეწას უთმობდნენ ადგილზე, ვიდრე იმ მექანიზმების აღდგენას, რომლებიც გუნდს უკვე აქვს სხვა პროდუქტისთვის. საერთო საფუძველი არ ამცირებს ინდივიდუალური ინჟინერიის შესაძლებლობას; ის იცავს ამ ძალისხმევას ინფრასტრუქტურაზე გადასვლისგან.
ნამდვილი გამოცდა მაშინ დგება, როდესაც გუნდი მეორე პროდუქტს იწყებს.
კარგი პლატფორმა შემდეგ პროდუქტს პირველზე აადვილებს
თუ მეორე პროდუქტი თითქმის იგივე პლატფორმულ მუშაობას მოითხოვს, რასაც პირველი პროდუქტი, სინამდვილეში ძალიან ცოტა რამ არის ხელახლა გამოყენებული.
ახალ ვარიანტს უნდა შეეძლოს ოპერაციული მოდელის იმ ნაწილების მემკვიდრეობით მიღება, რომლებიც არ შეცვლილა: უზრუნველყოფის ნაკადები, იდენტობა, სასიცოცხლო ციკლის მექანიკა, ფლოტის ინსტრუმენტები, პროგრამული უზრუნველყოფის პროცესები, მხარდაჭერის ხილვადობა და საერთო ინტეგრაციები. შემდეგ საინჟინრო ძალისხმევა მიმართულია განსხვავებებზე — შესაძლოა ახალი სენსორული პაკეტი, სხვა საკონტროლო სამუშაო პროცესი ან მომხმარებლისთვის სპეციფიკური ინტეგრაცია — საძირკვლის რეკონსტრუქციის ნაცვლად.
აპარატურის ახალი თაობა იმავე იდეას კიდევ უფრო მეტ ზეწოლას ახდენს. მისი შესაძლებლობები შეიძლება მნიშვნელოვნად შეიცვალოს, სანამ ძველი დანადგარები აქტიურად დარჩებიან სფეროში. განვითარებული პლატფორმა შეიძლება ორივეს მხარდაჭერას უწევდეს გუნდისთვის ორი ცალკეული პლატფორმის შენარჩუნების იძულების გარეშე, რასაც მომხმარებლები კვლავ ერთ პროდუქტის ოჯახად აღიქვამენ.
არცერთი ეს არ საჭიროებს ერთ მონოლითურ ბექენდს. სხვადასხვა პროდუქტს შეიძლება მაინც დასჭირდეს მკაფიო არქიტექტურული საზღვრები. მნიშვნელოვანია იგივე საინჟინრო პასუხისმგებლობის მეორედ განხორციელების თავიდან აცილება საფუძვლიანი მიზეზის გარეშე.
სწორედ ამ დროს ხდება პლატფორმა აქტივი და არა დაგროვილი ზედნადები ხარჯები. მხარდაჭერის სამსახურს ნაკლები პარალელური ინსტრუმენტი აქვს გასაგებად, ვერსიები უფრო თანმიმდევრულ გზებს მიჰყვება და კიდევ ერთი პროდუქტის დამატება კონტროლირებად გაფართოებად იქცევა და არა კიდევ ერთი ბექენდად, რომელსაც კომპანია განუსაზღვრელი ვადით მემკვიდრეობით მიიღებს.
პლატფორმას პროდუქტის არქიტექტურის ნაწილად მიიჩნევთ
ფიზიკური პროდუქტები შექმნილია რედაქტირების, მომსახურების, წარმოებისა და მომავალი ცვლილებების გათვალისწინებით. დაკავშირებულ პროდუქტებს პროგრამული უზრუნველყოფის მხრივ იგივე დისციპლინა სჭირდებათ.
პირველი ბექენდი შეიძლება იყოს დროებითი. ასევე შეიძლება იყოს პირველი დებულების სკრიპტი ან დამხმარე ინსტრუმენტი. ამაში არაფერია არასწორი. პრობლემები იწყება მაშინ, როდესაც ეს დროებითი მექანიკა ჩუმად გადაიქცევა მუდმივ არქიტექტურად, სანამ თავად პროდუქტი აგრძელებს განვითარებას.
ამ დროისთვის, დაკავშირებული პროდუქტი აღარ იქნება მხოლოდ აპარატურა, პროგრამული უზრუნველყოფა და აპლიკაცია. ის ასევე დამოკიდებულია ინფრასტრუქტურაზე, რომელიც ამოიცნობს თითოეულ მოწყობილობას, ესმის მისი შესაძლებლობები, იყენებს სწორ კონფიგურაციას, მხარს უჭერს განახლებებს და ეხმარება გუნდებს პრობლემების დიაგნოსტიკაში გაგზავნიდან წლების შემდეგ.
როგორც კი ეს ფენა პროდუქტის არქიტექტურად განიხილება, დაყოფა უფრო ნათელი ხდება: სტანდარტული მექანიკა ხელახლა გამოსაყენებელი რჩება, ხოლო ინდივიდუალური მუშაობა იმაზეა დამოკიდებული, თუ რა განასხვავებს ერთ პროდუქტს ან პროდუქტის ოჯახს მეორისგან.
ყველაზე ძლიერი პლატფორმა არ არის მხოლოდ ის, რაც შესაძლებელს ხდის პირველი დაკავშირებული პროდუქტის შექმნას. ეს არის ის, რაც საშუალებას აძლევს ინჟინერთა გუნდს შექმნას მეორე, მესამე და მეოთხე, ყოველ ჯერზე ახალი ბექენდის მემკვიდრეობით მიღების გარეშე.
