Blog BN′B

BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-12

saltuzzo | 29 July, 2018 14:46

Part 12: IoT Core Platform Development - Product Description Documents
The IoT Embedded Core Platform -Creating Conceptual Design Documentation

"The goal of education is not to increase the amount of knowledge but to create the possibilities for a child to invent and discover, to create men who are capable of doing new things." - Jean Piaget

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)

Quick review to set the atmosphere for Part 12:
From the previous Internet of Things Part-1 through Part- 10:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview → Basic → Detailed (OBD).  We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The atmosphere has been set for the Internet operation overview in parts 1 through 11.
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • The internals of the embedded processor IC's peripherals assignments.
  • Documentation categories, requirements, review & creation.

What we want to cover in Part 12:
OK, we have covered interesting technical stuff for the overview of what our IoT core Platform should be.  We got through the difficult review of the documentation requirements for a product development project.  Yes, I know the temptation is still there from the past parts, the excitement and anticipation of just jumping right in and designing the hardware and software on the fly and documenting it later, the consequences have not changes either.

Lets start with putting together the front part of the product documentation for the project - the overall functional blocks that we have to design.  This will give us the guidelines to create specific parts of the documentation for the project and how the documents should interact with the Interactive Product Development (IPD) System relational databases.

Lets Get Started:
The Innovation Process - Starting a New Development Project
The creators / innovators mind-set are all wired differently and face unique challenges in business when putting a product or product line together for development.  The entrepreneur mind-set, the small company mind-set and the large company mind-set, all have their pros and cons.  Regardless be it entrepreneur or company, at the end of development the documentation should be the same prior to entering a manufacturing environment.  The processes are very similar, the conception of the product or product line, the creation of the high level business presentations that sum up the costs and market risk to obtain the business go-ahead, the technical presentations detailing specifications, testing and validation to solidify the budget "expectations" to create Proof of Design (PoD) and Proof of Manufacturing (PoM).  Then the manufacturing requirements presentations for supply chain, manufacturing costs, testing, packaging and build size.  The differences between the entrepreneur, the small company and the large company are the Return on Investment (RoI) statistics, development resources and of course time to market. Prior to the PoD or PoM the only deciding factor is the accuracy of the documentation created to present the project.

For a large company to enter a market arena, marketing has to show the expected RoI that meets the company guide lines for product development.  For a small company the analysis is similar however the RoI numbers are smaller since the overhead is much smaller.  For the entrepreneur it is generally the question of are the overhead bills being paid, what will the initial prototype cost and will the market bring in a profit for a few years.   The documentation process should still end up the same, however less costly for the entrepreneur and small company.

One of the rewards in engineering is the confidence that is built from developing a project from conception to fruition.  Our intent with this series is to build a solid ground for that confidence in all that participate in this development.  There are as many different approaches to innovation as there are those's that develop them.  

The ones I have found to be most useful is being able to map out a 50,000 foot radial mapping of the innovation's core, then breaking down each segment until the detail is adequate for applying to a physical design.  Radial mapping or tree map is centuries old allowing an easy way for the mind to think conceptually Outside-the-Box to organize a multi-tentacle project, which is the closest to a flexible logically, not necessarily scientific approach to create.  Radial mapping over the years has surfaced in many forms such as radial tree maps, fish bone maps, mind maps and many more that the mind may imagine.  What makes this approach interesting is that every individual that incorporates it into their innovation process tailors it to their own mind and that is a key element that unleashes the brain power to move forward with the development.  The capability of the human mind is endless if allowed to think unconventionally.

Conceptualizing a Product:
The conceptual presentation is a very high level "limited detail" type presentation that is generally presented as a first pass to business investors to obtain the proper interest to move forward with the development, short and to the point.  Conceptualizing a project starting point is up to the creator and how the mind is wired for innovation.  Individual minds are all wired uniquely and what ever the starting point is it will usually branch out to connect all the blocks while mapping the project.  As the author the choice is mapping out the high altitude (50,000 foot looking down) functions and working towards the transformations of each segment increasing the details for the actual functions layout, remember this is not the physical design it is the conceptual layout of the IoT system.  Getting from conception stage to the actual development and project management stage is what this part of the series is presenting.

The high level mapping figures are ideal for the business presentation document showing the conceptual overview with enough detail to give an understanding of the actual product or product line.  The process of perspective at this level allows the mind to be more open as we add more detail to each segment.  The process usually takes three or more levels to fully transform from the high level to the detailed level as it becomes more complex for the physical development as we will see.  Assigning names to each level is important for traceability as well as organizational development purposes and allows the Interactive Product Development (IPD) system to be an effective tool for Requirements Traceability Matrix (RTM).  Assigning this as the "IoT_Conceptual_Presentation Document" with a series of sub-levels defined as "Segments" to be easily added to the IPD.

That being said, lets look at our project and start building the documentation to guide us through the development with confidence.  Organizing all the information we covered in the past 11 parts will now be put into a set of documents that will guide us to the successful development of the project.  The IoT Platform as we easily see has many technologies that have to be addressed and interfaced together for a fully functional platform, so lets look at a high altitude view of the projects functional components as shown in Figure 12.0 below.

Figure 12.0 shows the conceptual top segments that will make up the IoT Platform device.  The five high level map segments of the IoT Platform are the basics of the IoT Platform.  Each segment has its own details that we will break down in the following figures.  We will gradually transform the mapping convention to move toward technical details to begin the hardware and software design stages.  Generally at this level the mind already starts to vision the details and plays out scenarios for the platform arranging the detailed sub sections of each segment allowing it to form the product.  This should be easier since we already prepared the mind to conceptualize the product in the past 11 parts of the series.

IoT_Top_Level_Functions
Figure 12.0  IoT Platform Conceptual Function Top Level Segments Map

Radial Mapping The IoT Platform Segments:
The interconnections to the segments are not shown at the highest level in order to give a high level description of each map segment.  This it pass one of the initial IoT Platform outline and may change as we proceed with detailing each segments function for development.  The fixed scientific process would not easily allow backtracking changes which is why Out-of-the-Box flexibility is a true leverage for the entrepreneur and small company, larger companies would have to have meeting after meeting to get pass the required process levels to continue development.  This slide is the "IoT_Conceptual_Presentation - Top Level Segment Map" -Page-1 of the document and consists of the following segments.

The Main Processor Core
The main processor core that we discussed in part 10, Figure 10.2 is used for all the standard operating system embedded functions and book keeping.  There are many applications where only one processor is adequate for all the control requirements, that is not the intent here for our IoT Platform.  It will have the capability to be used in critical infrastructure devices with the maximum security features to prevent hacking.

The Main Core Memory
The Main Core memory is used by the embedded operating system to monitor and control the internals of the IoT Platform.  This memory is not accessible from the outside world and is a supervisory and control memory.  It consists of parallel flash and a general purpose R/W RAM for S&C functions.  The status of the S&C are sent out to the Applications Core Processor for real time updates of the IoT Platform.

The Applications Core Processor
The Applications Core Processor is used for all the applications data from the sensors and other peripherals connected to the IoT Platform.  The ability to add a second processor is dependent on the complexity of the IoT Platforms end application.  If it is a small application then the Main Core Processor may be capable of handling the application functions.  This is usually the case where heavy encryption is not required and communications is generally kept in a closed network.

The Application Core Memory
This memory is used for more complex applications and would consist of a parallel FLASH capable of running the programs directly from FLASH along with some R/W RAM.  Additional storage memory like serial EEPROM if required, otherwise a R/W static or Dynamic RAM would be used for later transmission to the real world.

The Interface Device Segment
The Interface peripherals depend on the type of application the IoT Platform will be used with.  We have talked about having a separate peripheral control processor if the application is very complex and required "fast" real time monitoring & control, otherwise the applications processor may be used if the loop time for the application will fit the timing characteristics of the processor being used.

MAIN IoT Platform Processor Core:
OK, here is where the conceptual presentations takes the first step to transform into the design documents.  It is still a conceptual mapping presentation at this level with a bit more detail for the business to see the depth of the product as a user and not technologists.  

The MAIN Processor Core for the IoT Platform performs the watchdog timer monitoring of the IoT device as well as supports the selected Operating System (OS) that is embedded.  If more than one core is incorporated for the application the main core will handle the communications of the other cores and will incorporate the I/O Memory Transfer Management module for memory to memory transfers between cores.  In a multi-core platform each core will be independent with unique communications between them in order to have different control mechanisms for security and privacy operations.  This slide is the "IoT_Conceptual_Presentation - Core Processor Segment Map" -Page-2 of the document and consists of the following segments.

PICTURE_IoT_images/IoT_TopLevel_MainCore.jpg
Figure 12.2  IoT Platform MAIN Core Processor Segments Mapping

MAIN Startup Routines:
This is the Power-On Initialization or BOOT section of the platform.  This is a sealed part of the IoT Platform and is not accessible to outside influence.  Being in a OTP (One-Time-Programmable) part of the FLASH usually a Top-Boot or Bottom=Boot section of the FLASH depending on the processor core being used and the initial Power-On default Memory access the processor initializes the instruction fetch.  There are many version of a Secure Boot process in many desktops in today's desktops, laptops and smartphones that also have published vulnerabilities.  The simplest way to insure that it cannot be tampered with is to block all access form the power on sequence.  This is one of the reasons the IoT Core processor is an independent entity for the rest of the system and communications is controlled once the boot cycle is completed.

MAIN Operating System Program:
The Main Operating system is also part of the FLASH that contains all the OS's functions and are not alterable.  If you incorporate an update re-FLASH program into the Platform you are now open to vulnerabilities.  This means that the OS has to be well tested and capable of handling many of the features that are to be included in the platform. A TBD (To Be Determined) or a SWAG applied to the software segment in the beginning may cause the development process to exceed budget as well as possibly fail to be completed in a normal time frame.  Putting this on the table up front now will keep the mind-set in place when detailing the development specifications.  Remember functionality requirements are relatively straight forward to organize at today's technology level.

MAIN Hardware Diagnostics Library:
The Hardware Diagnostic library is another important roll in maintaining the functionality of the platform.  To insure security it is requested to uses several different encryption algorithms that includes obfuscating segmentation of the diagnostic firmware in storing it to FLASH to prevent tampering with the code.  This code would be incorporated at the application level of the development in order to perform the applicable diagnostic algorithms for the application.

MAIN Core Processor Physical Memory:
The main core memory would consist of the internal FLASH along with a R/W RAM for temporary functions and a block of  R/W RAM for storage and inter platform communications.  Generally the memory is controlled by the core MMU, however MMU generally have R/W RAM connected to it and also have a fixed number of virtual task and memory protection.  We will look at the ones that allow fixed permanent block for FLASH to be incorporated within the virtual memory block.  If we block this effectively we may not need the MMU at all if we are able to secure the section.

[Section_Menu]     [Top_Menu]

Application IoT Platform Core Functions:
The application portion of the IoT Platform for our development will have its own core processor as shown in Figure 12.1.  This shows both hardware and software mapping blocks for the application segments of the platform.  This is a conceptual mapping of the application segment for any application applied to the IoT Platform.   The common functions are the Internet Protocol Library and the Encryption/Decryption Library segments that will be available to all application programs if required.   A separate MMU (Memory Management Unit) is common for today's embedded single and multi-core processors.  The decision that has to be addressed is should the application have a separate physical hardware processor or should it be a multi-core processor chip?   The Application core processor should include enough memory to handle the interrupt system code as well as some RAM for direct memory access to maintain a steady periodic data throughput to address any time variant data collection and/or analysis.  This slide is the "IoT_Conceptual_Presentation - Application Processor Segment Map" -Page-3 of the document and consists of the following segments.

PICTURE_IoT_TopLevel_Applications.jpg
Figure 12.1  IoT Platform Application Function Segments Mapping

Internet Protocol Library:
The Internet Protocol library are the set of Internet Protocols that this series selected to be incorporated into the IoT Platform.  We put these protocols in the application segment since it would be faster to transfer and process the Internet data from a DMA block if higher throughput is required.  The memory type would be capable of executing instructions directly to the Applications Core Process through the Application memory Management Unit (AMMU).  The library includes the standard Internet protocols, TCP, ICMP, UDP and several others as required by the specific application.

Encryption-Decryption Library:
The Encryption - Decryption methodologies are to be discussed when we get into the security and privacy of the device.  Encryption of data transmitted is a useful tool from Man-In-the-Middle (MIM) attacks that try to intercept data and the URL tags assigned.  There are many algorithms out there like AES256, DES, Elliptical and others that may be applied to this runtime library.

Application Programs:
This is where the actual IoT Platform is applied to the application.  All programs that are used for the application are in this runtime library

Application Memory Management Unit (AMMU):
The Application MMU is part of the dedicated Application Processor configuration and is recommended for memory protection and management..  As stated previously MMU within the embedded market have specific constraints and would be determined by the size of the application. It is added here now in the beginning and may be easily ignored if not required for memory management of the application.  The AMMU handles all the library functions in the library segments, again this library as the others are part of the parallel FLASH and are able to run the tasks directly from the FLASH to the CPU.

Application Core Processor Physical Memory:
The Application core processors physical memory run the real-time applications for the IoT Platform.  The intercommunications between the cores is accomplished via the I/O Memory Transfer Management unit that has a DMA controller to handle direct physical memory to memory transfers.  This block of memory us separated from the Memory Management Unit.  The DMA RAM acts as a real-time data storage area for the peripherals.  The core processor is interrupt driven to handle the several interfaces that it controls.

[Section_Menu]     [Top_Menu]

IoT Platform Peripherals:
Peripherals the main connection to the real world environment as well as peer-to-peer communications.  Many embedded processors integrate several peripherals in order to create a complete application on a single chip.  With the changing technology and the mergers and acquisitions directs us for our platform to keep the peripherals separate from the core device and incorporate a separate processor to handle real-time communications of the peripherals.  There are no direct rules or reasons not to utilize the on chip peripherals at this level except for the discontinuance of the embedded processor chip itself.  The actual application will determine if a separate processor will be required to maintain the application throughput requirements.

For this platform development we will incorporate a separate peripheral processor in order to run the peripherals asynchronously in real time for the maximum throughput and increased control over the peripherals. The peripherals will have a separate BUS structure that is connected to the peripheral processor that will allow the flexibility of incorporating the separate processor or using the core or application processor if the application throughput fits within the processors specifications.

The peripherals interface is a key factor in determining application processing throughput to control the specific application it is designed to control.  This slide is the "IoT_Conceptual_Presentation - Peripherals Processor Segment Map" -Page-4 of the document and consists of the following segments.  This is the last slide of the conceptual presentation and we will put this in a Visio presentation format and incorporate it into the IPD with the filename "IoT_Conceptual_Presentation.vsd". LibreOffice Impress or Power-Point which ever is more suitable to you environment.

PICTURE_IoT_images/IoT_TopLevel_Interface_Map
Figure 12.3  IoT Platform Interface Function Segment Mapping

Devices Core Processor:
Considering today's peripheral complexity it would be advisable to incorporate a separate processor to handle all peripheral communications, that is unless you are just building a simple controller like a toaster.  The Core processor will be very active collecting data and processing the data to the applications processor.   Timing is everything when collecting real-time data for analysis and control.  The peripherals processor could also be part of a multi-core embedded processor chip, however does not have to be.  For longevity the use of an FPGA processor would be efficient and if it is a standard FPGA core processor most  licenses are perpetual and as long as the FPGA is available the designs will remain stable.

Device MMU & Physical memory:
The peripherals memory allocation will vary for by the application, the standard memory within the embedded processor of 2 Megabytes may handle many of the upper level applications.  For Direct Memory Access the PHY DEVICE DMA Controller will control where the data will be passed to.  One of the processors we will be evaluating for this platform allows 134Meg Dynamic RAM that may be uses as peripheral data or program data and allows memory management and protection.

Peripherals are a dilemma in this embedded arena which is why we will evaluate external devices like the FPGA and CPLD for them.  FPGA's and CPLD's are generally CPU independent, however many of today's FPGA's allow a standard 32 bit core processor that may be incorporated as well for total control of the peripherals.  This does answer the argument of discontinued or obsolete processors.

Physical Device DMA Controller:
A DMA controller is also recommended for the peripherals interfaces for real-time periodic data I/O.  The DMA controller is dependent on the applications timing and interface requirements.

SQI & Storage RAM Controller:
The Serial Quad Interface is mainly for SQI FLASH storage since it uses 4 data line and is able to transfer data at faster rates as well as higher capacity than tradition serial devices.   SQI devices are available in both RAM and FLASH from several suppliers.

Ethernet Controller:
The Ethernet controller is the key controller for the IoT Platform since it will be connected to the Internet in some way.   There are a variety of controllers on the market today and some of the embedded processors also have an internal controller in the peripheral block.  We will look at keeping the Ethernet controller independent of the processor in order to have tighter control over the communications process.  We will address the control when we present the security section of the series as well.

Parallel Interface Controller:
The Parallel interface is used for all those other peripherals including straight digital I/O.

Serial I/O Controllers:
All the standard peripherals like serial I/O and parallel I/O have reference designs on line that have been proven over and over again as well as being open source and free to use in a design.  

Software - Firmware Device Libraries:
The Driver library is key to the peripheral performance and if an FPGA processor is selected then the peripherals are all connected internally to the bus and may have a timing advantage as well as a software driver advantage.  There are advantages to creating the I/O Peripheral platform I an FPGA with an internal Processor.   If the FPGA evolves into a new series with more capability, it is easily transferred as has been the case with Altera, Xilinx and many others.  The other advantages are firmware drivers for the peripherals.  Once validate they remain in a perpetual functioning state until the user decides to update them.   Software is still one of the most expensive contributions to the total cost of development and always will be for some time.

[Section_Menu]      [Top_Menu]

Brief Overview of the Interactive Product Development (IPD) System:
As we stated many times during this series that product development of any type requires a unique mind-set and documentation of thoughts and mind-set are essential for a successful product.  What is needed is a Interactive Product Development  system at the project level that is extremely flexible and organized in such a way that creating the documentation is as sequential or random as the individual mind-set that is creating the product.  As we stated there are many categories of documentation during a development project and the IPD addresses these as an open interactive system.  The user can create segments of each layer of the required documentation as the innovation process develops with the flexibility to return to the selected document sections to pick up where left off to continue the development.  OK, a system like this does exist in large companies and takes a while to learn the ins and outs, however as entrepreneurs and small companies we need something less cumbersome and intuitive as well as organizational to use.  

The IPD system main menu has all the different documentation categories that cover all the databases presented as shown in Figure 12.4 shown below, and operates as a project base system.

IMAGE_Databases_of_IPD
Figure 12.4 Interactive Product Development (IPD) System Relational Databases

Project based system architecture is the fundamental organizational rules for development and allows compartmentalization by incorporating separate directories for each project and sub-directories for each category of the project.  The IPD directory structure is shown below in Figure 12.5.

IPD_Directory_Structure
Figure 12.5 Interactive Product Development (IPD) System Directory Structure

Below is the IPD system application programs Opening Dialog to show how the system is organized for easy access of each project category.  The IPD System will be available at the end of the series with added features from readers comments from this series.  There are several Reserved buttons for expansion of the program for those that wish to contribute, send me your request either in a file or message using the Contact Form.  To date this program runs on Windows XP,  Win7.x, Win8.x, and Win10 either directly on the local machine drive or on a server.  Since these are development files and are generally proprietary to the developer it is not recommended to put the development directories on an Internet cloud.  A private in house server with controlled access is recommended if run from a server that is not connected to the Internet.

IMAGE_IPD_TOP_MENU
Figure 12.6 IPD Interactive Product Development System Top Menu

Maintenance Categories

Archive  / Restore

Archive / Restore by Project or full System

DB Tools

Database Maintenance, DB Pack, Create, Move, Copy, Add  etc.

Encryption / Decryption Tools

Full AES256 set of encryption tolls - Not Part of OS

Rich Text Editor

Rich Text Editor for general abstracts of all files saved by IPD system

Component COTS

COTS Components System Library, Resistors, Caps, Inductors, hardware etc.

Components Custom

Custom Components Electrical, Mechanical Project related

Reuse Modules Validated

List of Reuse modules and where currently being used

Products Library Validated

List of Products developed and Modules used

Projects Available

Projects listed in the current Projects Database

Default Directories

Used for initial startup of a project.

Project Related  Documentation Categories and Directories

NEW Project

Create a New Project

OPEN / Edit Project

Open / Edit Existing Project

Presentation Documents

All Presentation Documents by Project

Legal Documents

All Legal Documents by Project

CAD - Documents

All Computer Aided Designs Docs by Project

Firmware & Drivers

All Firmware and Software Drivers by Project

Software API's

All Software Applications by Project

ECO Documents

All Engineering Change orders by Project and Category

Internet Protocols

All Internet Protocols Software

Components COTS

All Components COTS by Project

Components Custom

All Custom Competent by Project

SUMMARY:
Development documentation is and always will be a critical part of product development.  This is even more critical when it come to software coding and revision traceability.  There are thousands of lines of code free on the Internet, however when you try to read how it works there are little or no comments.  During the computer revolutions early days at Digital Equipment Corp (DEC) the programmers were trained and required to keep all library routines at a complexity level of 5 on a scale of 10 and easily understood code comments explaining the library function use requirements.  Somewhere during the new wave of software development this rudimental format got lost.   Revision traceability also pertains to hardware revision, schematics, PCB Layout, Mechanical and assembly control.  The IPD system keeps the current revision a click away and previous revisions in the project level sections keeping them compartmentalized to prevent confusion and accidental release.  Documentation discipline is either not covered or little time is given to the subject in technical schools or colleges in engineering technology and is left to the individual companies to introduce their method of development documentation.

Part 13  "Preliminary Outline" Embedded Processor Systems Hardware: -Continued

  • Creating Requirements and Traceability Documentation
  • Extracting the specifications from the series to date

More to come in the series

  • Protocol Hardware - Ethernet
  • HS-USB
  • WiFi devices
  • Bluetooth Devices
  • SQI, SPI, I2C,
  • Analog Inputs, Analog Outputs
  • Digital Parallel Ports
  • PWM ports
  • Software tools for embedded processors
  • IDE- Integrated Development Environment
  • Macro Assemblers
  • Compilers
  • Hardware Design Tools
  • and more ....

Reference Links for Part 12:

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-12  Product Development Management - (July 29, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=17&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-12 Product Management: <i>Continued (July 29, 2018)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Product Design - IoT Hardware/Software | Permalink | Add comment | Trackbacks (0)

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-11

saltuzzo | 27 June, 2018 17:17

Part 11: IoT Core Platform Development - Product Development Management
The IoT Embedded Core Platform -Design Documentation Processes

"There is no greater impediment to the advancement of knowledge than the ambiguity of words." - Thomas Reid (1710-1796)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 12 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (July 29, 2018)

Quick review to set the atmosphere for Part 10
From the previous Internet of Things Part-1 through Part- 10:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview → Basic → Detailed (OBD).  We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The atmosphere has been set for the Internet operation overview in parts 1 through 10.
  • The Ethernet physical protocol is the most used for communications over the Internet.
  • All communications throughout the Internet is performed as User↔Router↔Internet Routers↔Router↔User
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • Basic types of CPU architecture on the market today
  • The internals of the embedded processor IC's peripherals assignments.

What we want to cover in Part 11:

OK, we have covered interesting technical stuff for the overview of what our IoT core Platform should be.  At this time we will cover the basics of documentation, records we should create to insure our design policies and guide lines are covered properly to insure a successful project development.

Yes, I know the temptation, the excitement and anticipation of just jumping right in and designing the hardware and software on the fly and documenting it later, did that many years ago several times and found that way was not very productive during the testing and troubleshooting stages of the development, ended up almost redesigning the device.

Since this is an educational project, lets set some healthy design practices to follow that we may use for many innovative designs to come.  We will discuss the basic requirements of an Interactive Product Development (IPD) System that uses relational databases for our development guide and make this system available at the end of the series.

Lets Get Started:
A Brief summary - Documenting Design Processes:
OK, This part of the series is about product development documentation discipline, I know engineers and experimenters just want to dive in and start connecting parts together on the bench and see what comes out of it.  That is OK, I still feel like that after all these years and at times just do that for a one time only design.  Go for it, you can always refer back here and learn the documentation discipline when you are ready for it.  

During my career one of my mentors stated that if you want to be a product development engineer you have to be responsible for problems that arise in manufacturing, hence, design the product for manufacturing because you will be directly involved in the testing and troubleshooting AND - problems do arise when going from Proof of Design (PoD) development to (PoM) Proof of Manufacturing.  Also just because the PoM worked, there will always be some issues when ramping up to quantity in manufacturing.   When a computer and software are part of the product it is a challenge to anticipate the full variations for a FMA (Failure Mode Analysis) matrix.

The advantage of writing a blog on product development is that we have the opportunity of writing about experiences in order to help the young engineer enter into the world of product design.  To maintain a positive point of view always even when addressing difficult problems that appear negative.

OK, lets address an on going issues of how a project schedule and budget gets out of hand, not something new, it has been an issue of the 38 years I have worked in the industry and it is independent of the field be it building facilities, homes, or computers or whatever.  The concept of going into business to sell product is to make a profit.  If you go over budget including time, the results are less profit and in some cases end of product and possibly company, so in order for this series to be both effective and efficient we should present an approach that addresses both. Oh, did I mention documentation processes, TBD (To Be Determined) and of course SWAG's (Silly Wild A$$ Guess) ?   "SWAGs and TBD will get you in difficulty every time, it is the way many larger contracts are compiled in order to compete and win the contract, only to pay the price later.  The more accurate the documentation is up front the better chances of a successful product development.

Traceability Documents
Experiments and development to maintain traceability in a document form has been an on-going challenge for over 100 years of the industrial revolution.  From Taylorism to the McNamara's WizKids and the implementation of Game Theory that is in all aspects of our lives.  What is interesting is you would think that after all these years the product development processes would have thinned out and stabilized.  As we stated in the previous part, scientific management systems work great after the product is fine tuned in manufacturing, it is still not very effective or efficient during the development process. Wow, sounds too negative, lets look at it a more positive way that is applied to startups and the geniuses that have a dream as with every startup.

Rational organization documents during the product development stages are considered by many designers as an "out-of -the-box-mind set" and should not be confined to a fixed scientific process mainly due to the fact that the innovative mind incorporates way too many variables as well as rapid change of direction to attempt creating a scientific formula to represent it at least during the innovation processes, after the initial design testing is another issue.  There are many documents that may be applied during product development and is usually refined at different stages of development, however it is not a totally spastic process, there are processes for parts of the innovation process, they are just better performed if allowed to be rearranged at times during the development.  They all should be completed by the end of the development cycle prior to being moved into a manufacturing environment, again which is a completely separate process for compliancy and unique validation.

There are many relational databases available but only a few real product development type relational databases that allow the storage of product development facts and data to allow Requirements Traceability and a Rational Cross Referencing Matrix, too many words for an acronym, however the short form is (RTM) Requirements Traceability Matrix, sound familiar?

Pros & Cons of Relational Databases and Spreadsheets:
Databases and more databases and spreadsheets to store and document information into a "data warehouse" of data.  There are many database software packages on the market today and many of them are able to be integrated into MS Windows® Visual Studio and Linux type operating systems to organize information.  The issue is an application that addresses an Interactive Product Development (IPD) environment.  Many database servers like MySql, PostgreSQL, MariaDB, MongoDB, SQLserver, NoSQL and the list goes on for the creation of the database interactively, however data input and retrieval are based on the actual application to retrieve the data in the proper form that makes an application useful.  Storing warehouses of data is relatively easy, retrieving and organizing the data to have proper meaning toward an application is another issue altogether, that is where a good Interactive Product Development system becomes priceless when traceability for components, modules, compliance and requirements need to be reviewed and validated to name a few of the advantages.

Relational Databases:
Relational Databases are a group of digital database tables that are based on a configured indexing model which allows all databases to be aligned to the related indexes for data retrieval and insertion based on the configured model. The relationships are related to a top level index such as the project ID and secondary indexes that allow sub-sections of the project to be retrieved synchronously to generate reports.  There are more advantages to using relational database tables for Interactive Product Development processes than there are disadvantages as many designers have debated.  BASIL Networks has developed a series of small data gathering formats and file that allowed us to interface with various clients document formats and as many SMB manufacturers do not have a full integrated system as some of the larger manufactures that have the financial resources to either develop or purchase.

Spreadsheets Pros and Cons:
Spreadsheets have many great applications for business, however when they are used for technical computations or as a pseudo database we get into difficulty.  Spreadsheets are and X/Y, Row/Column cell format and using them to do complex math and system design causes cell identification issues for understanding a computational process.  The way that the cells perform complex math like averaging multiple cells may be different when performing max/min error analysis on several connected modules.  A true max/min ripple analysis requires an iterative process for each connective modules max/min output to be used as the next modules input variable until all the max/min combinations of the modules are tested,  for 3 modules connected in series that would be 26 =  64 iterations for the 23 for max and 23 for the min data sets.

Many designers use a spreadsheet for the Requirements Traceability Matrix with test cases in a Row/Column format that may also get complex and difficult to read if there are many test cases to handle. Database tables on the other hand are easier to generate a report of any complex relationship and test cases as well as performance results for clarity.

Database Structures, Relationships, Reliability Traceability Documents:
So, for our core IoT Platform we will use the rational organization approach and integrate some relational database methodology that will incorporate MDM (Modular Design Methodology) that may be useful for many years to come. Since this is a core platform that may be applied to many of these critical industrial areas we will document the development and all components used for reliability and traceability to insure the maximum integrity of the core platform.  

Large projects are generally broken own into smaller sub-assembly modules that are categorized for "reuse" in other projects.  A relational database referencing these modules is a required tool for the systems developer, however reuse has issues as we will cover in the MDM section following.

There are many document types presented during a product development process since many different functions of a corporation are involved and require different document formats for each of these functions, of course all requiring access to the documentation system.  This is where the IPD systems becomes the key asset in the success of completing a project.   The IPD system should be considered a living system for tracking the development of a product from financial, marketing, engineering, testing, validation, certification,manufacturing and sales.  That is a lot of different information formats and types to handle.  Attempting to handle all this data independently without relational database structures flexible formats would make managing a complex project vulnerable to missing data for accurate status, hence the relational database system retrieves up to date status information for many departments working on the project.

These database tables will allow complete traceability during the development process and a index database table that keeps track of how each of these database tables are to be indexed for data retrieval.  The largest of these tables is the component databases, it is obvious that we do not want to be a parts distributor, however we would like a complete set of information on each part that a project uses including multiple sources and timelines for the part.  Many printed circuit board design packages do allow for integrated component selection, however they are limited to the electronic design of a board.

The Interactive Product Development relational databases have several common corporate wide databases that are used to manage the development, the main set of databases that are independently maintained usually by supply chain management are the components databases.  Components or parts databases are a unique set of databases that categorize all the raw parts used as a resource for the product development.  There are many categories for components and are broken down into several databases with the links to add other component categories as needed for growth.  The remaining databases are relational to the projects of which data may be retrieved for each of the several functions for reports and real time information about product development processes.

Many small and especially startup companies are slack in the documents and focus on getting the product to market first only to find later the cost of poor development documentation is very costly.  Implementing an Interactive Product Development system initially saves time and money as the product matures and the company grows.  Reports may be generated easily during the development process to manage the development process effectively, yes it does require discipline to enter the data as required during the development, including design notes that the designer encountered especially during test cases.  Entering data is where many designers negligent for many reasons and we all have our reasons, regardless, developing good engineering practices in the beginning pays off at the end.

The typical  Interactive Product Development system set of relational databases are outlined in Figure 11.0 below.  As we see the relational database with multiple index relationship functionality is a definite requirement to interconnect all the different information for project development tracking and analysis.  We will cover more on the IPD system prior to making it as a download for our readers at the end of this series.

As the author of this series I have thought of combining all the separate modules to create an IPD system for the Entrepreneur and have decided to give this an attempt using the document creations for this series.  The requirements are simple it has to interface with current day desktop and web applications easily, that is MS Windows, Linux, and Web Servers.  The use of  MySQL® table format is probably the simplest choice for all the IPD database applications since it is widely used, compatible with many operating systems and open source.  If you want to be part of this, click here to send me a note.

Since this is an educational series, BASIL Networks will be developing a full IPD system for those entrepreneurs that want to develop and manufacturer their own product lines from the processes we create during this series and will be available for downloading along with the Interactive BUS Protocol Development (IBPD) system at the end of the series.  

IPD_Databases
Figure 11.0 Interactive Product Development (IPD) System Relational Databases

[Section_Menu]     [Top_Menu]

MDM - Modular Design Methodology, The "Reuse" Module Dilemma:
Modular Design Methodology has been around for many decades in order to have manageability over large system developments such as the Internet, Automobile manufacturing and more that incorporate many sub-assemblies all connected together to form a product.  Well all this sounds great and is one of the main motivating leverages that drives the industry to the "REUSE" dilemma that modules can be reused for other projects, "however", not all modules are fit for reuse without extensive rework which puts the module outside of the plug and play requirements of the reuse category.

The reuse issue is a touchy subject matter for large corporations since the communications pipeline seems to get distorted as it travels throughout the engineering and management levels.  For larger corporations, hence automotive, aircraft, military weapon systems, power grid systems, cell tower base systems that all require full traceability down to the smallest component level, reuse would be great if it really existed to its full capability, however reality proves it does not, which sounds a bit oxymornic with today's data warehouses of information one would think that it would be easier to maintain more accurate records.

The Reality of Reuse:
In larger corporations the percentage of reuse modules "AS-IS" without rework is very small, over my 38 years in the industry the "AS-IS" module reuse appears to fall in the less than 5% region.  For modules that require 20% or more which is at the redesign point depending on the specific rework or specification change, average to around 30% over multiple product lines and require other system integration changes to incorporate them.  Beyond the 25% change region it should NOT be considered a reuse item and would or should be assigned a unique part number requiring full PoD, PoM, Validation and Certification.

Larger corporations still strive to develop modules for reuse within their organization and expect their in house technical expertise to perform these tasks over and above their normal assigned duties.  Do not get upset folks, this has been an active process for over 50 years that I am aware of, a little bit of positive stress bring out the achievers in all of us and is healthy for growth.  Some companies take the outsource approach expecting that "FFF" (Form-Fit-Function) identified the module as reuse even if from different manufacturers also has it pitfalls, this is the "Solutions Business Approach".  Many of these reuse endeavors end up costing more time, money and resources than it would be to manufacture a new item.  When we look at the evolution of the computer from the 1950's to present day we see many reuse examples of standardization that actually worked for the growth of the industry, hence: the Hard Disk Controller originally would require the reformatting of the drive if the controller had to be replaced. Today with SATA, controllers and drives are interchangeable. The standard graphics controller followed the standard 640x480 and 800x600 format regardless of any higher unique designs that required a custom driver. The USB and firewire, the keyboard and mouse controllers, these devices became the plug and play and followed the true reuse criteria of the industry.  The main reason is due to the fact that they became "Industrial Standards", however this is not true for many larger present day corporations as the Military Industrial Complex manufacturers that are constantly innovating and prototyping new technology and systems as well as the automotive industry that function much in the same innovative mode.  As with all technology and industries as the technology becomes widely used, standards are developed and the industry thins out to a few commodity players that have a large library of reuse modules such as the cell phones and CDMA modules, Bluetooth, WiFi, touch screen and camera modules.  

It appears that until a technology is understood and integrated into our everyday lives and becomes a standard the scientific manufacturing process such as Taylorism easily makes it a commodity for the masses.  In summary, technology changes fast, parts become discontinued, performance demands change continually and today's reuse module maybe absolute before its next application.  OK, enough for the industrial revolution history lesson, back to the IoT Core Platform development.

Document File Types and Data File Links:
There will exist many different document types during a product development cycle and keeping track of the different file types becomes a challenge.  Naming conventions for files and directories will help organize the development an information retrieval.  The directory naming convention used in the IPD system follows the same naming file and directory conventions as shown in the IBPD system shown in this site which has evolved over the years at BASIL Networks.  As for the document application software take your pick, however it is advised that the file formats should be compatible software to be able to communicate with other organizations outside your immediate development environment.

For Document creation many developers use MS Office, the startups and smaller entrepreneurs' find that open source LibreOffice is just as effective and efficient and allows easy read/write file exchange with other office documentation software.  At BASIL Networks, we use MS Office as well as LibreOffice in order to handle many different document types in the industry.  BASIL Networks IBPD system incorporates a general purpose Rich Text Format (*.rtf) editor we will also incorporate it into the IPD project since rich text formats are easily created via most word processors.  The RTF editor incorporated in the IBPD system is used for all abstracts of the different documentation file types that are linked via the relational database system, in some cases it may be used to outline the actual test setup.

Security, Intellectual Property
It is always a good idea to at least mention security and Intellectual Property since we are presenting product development processes.  It has been my experiences that ideas are a dime a dozen and many will forget they have been spoken, that is until someone applies that idea to fruition.  When there exists product it is at that point that the inclusive Intellectual Property (IP) becomes of interest to the hackers.  We all use computers to design, develop and create products with even being on-line during the process, which today is not a good practice to employ since many of the new processors have active management system internal to the processor chip.  It is recommended to uses an off-line (not accessible to the Internet (incoming or outgoing) when developing product that contain IP or trade secrets that you do not want to be hacked and sold to the highest bidder or worse.  Keeping a development server off line is not a difficult task, it is just a stand alone server that is connected to workstations, we have a few here and yes, we have desktops that are not connected to the Internet.  Encrypting all the development files is time consuming and at time a "Pain where the sun don't shine" however if you feel that the product you are developing is worth a large amount of money, then data protection has to be performed is some way.   We will cover real time encryption/decryption when we get into the software development stages for the series.  We are not concerned with encryption of this series since is a public education series.

With today's information hacking we do recommend a local off-line (air-gap, not wireless) server to save development files including the relational databases to insure some type of security from hackers.  Keep in mind that what ever you publish on-line should be consider open source for everyone and anyone to make copies regardless of any conditions you put with the publication.

[Section_Menu]      [Top_Menu]

SUMMARY:
Development documentation is and always will be a critical part of product development.  This is even more critical when it come to software coding.  There are thousands of lines of code free on the Internet, however when you try to read how it works there are little or no comments.   During the computer revolutions early days at Digital Equipment Corp (DEC) the programmers were trained and required to keep all library routines at a complexity level of 5 on a scale of 10 and easily understood code comments explaining the library function use requirements.  Somewhere during the new wave of software development this rudimental format got lost.   Documentation discipline is not covered is technical school or colleges in design engineering and is left to the individual companies to introduce their method of development documentation.

The challenge is to maximize module reuse and minimize the Total Cost of Ownership (TCO) of devices and equipment from a technical aspect as this series is based on.   The IoT Platform being presented here addresses the latest approach in product development to fine tune the technology and handle the changing business models and companies grow.

When we get to the physical hardware design we will be incorporating design software from Cadence for the schematic capture and PCB layout and Autocad for the mechanical packaging.  We will also present other formats for education purposes allowing the readers to follow with other design software.

When we get to the software development portion of the IoT Platform all routines will be flowcharted along with the appropriate code for the routine.  

As the author of this series I have thought of combining all the separate modules to create an IPD system for the Entrepreneur and have decided to give this an attempt using the document creations for this series.  The requirements are simple it has to interface with current day desktop and web applications easily, that is MS Windows, Linux, and Web Servers.  The use of  MySQL® table format is probably the simplest choice for all its database applications since it is widely used, compatible with many operating systems and open source.  If you want to be part of this, click here to send me a note.

Since this is an educational series, BASIL Networks will be developing a full IPD system for those entrepreneurs that want to develop and manufacturer their own product lines from the processes we create during this series and will be available for downloading along with the Interactive BUS Protocol Development (IBPD) system at the end of the series.  

Part 12  "Preliminary Outline" Embedded Processor Systems Hardware: -Continued

  • Creating Requirements and Traceability Documentation
  • Extracting the specifications from the series to date

More to come in the series

  • Protocol Hardware - Ethernet
  • HS-USB
  • WiFi devices
  • Bluetooth Devices
  • SQI, SPI, I2C,
  • Analog Inputs, Analog Outputs
  • Digital Parallel Ports
  • PWM ports
  • Software tools for embedded processors
  • IDE- Integrated Development Environment
  • Macro Assemblers
  • Compilers
  • Hardware Design Tools
  • and more ....

Reference Links for Part 11:

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 12 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (July 29, 2018)

 

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-11  Product Development Management - (June 5, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=15&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-11 Product Management: <i>Continued (June 25, 2018)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Product Design - IoT Hardware/Software | Permalink | Comments (2) | Trackbacks (0)

1 2 3 4 5 6 7  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2017 BASIL Networks, PLLC. All rights reserved
webmaster